RE: pg_group_name_index corrupt?

Coolness, that worked like a charm ... so I take it I have to do this for
each and every database on the system? :)

On Fri, 5 May 2000, Hiroshi Inoue wrote:

> > -----Original Message-----
> > From: pgsql-hackers-owner(at)hub(dot)org
> > [mailto:pgsql-hackers-owner(at)hub(dot)org]On Behalf Of The Hermit Hacker
> >
> > On Thu, 4 May 2000, Tom Lane wrote:
> >
> > > The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> > > > This worry anyone? :)
> > > > NOTICE: Index pg_group_sysid_index: NUMBER OF INDEX' TUPLES
> > (0) IS NOT THE SAME AS HEAP' (1).
> > > > Recreate the index.
> > > > NOTICE: Index pg_group_name_index: NUMBER OF INDEX' TUPLES
> > (0) IS NOT THE SAME AS HEAP' (1).
> > > > Recreate the index.
> > >
> > > Not if you had other transactions running in parallel with the
> > > vacuum --- if the vacuum was the only thing running then I'd want
> > > to know what you were doing before that...
> >
> > I can't guarantee whether i was or not :( right now, I'm assuming that
> > 'other transactions' would include any database on that server, not just
> > the database that I was vacuuming at the time, as even if I go in and do a
> > vacuum on 'template1', that error pops up ...
> >
>
> Why does pg_group exist under $PGDATA though the indexes exist
> under each $PGDATA/base/db_name ?
> Could it be consistent on all databases ?
>
> > It says to 'recreate the index', but if I try to, it tells me its a system
> > table (of course) ... is there a way of fixing this without having to do
> > a dump/reload?
> >
>
> Run "reindex table pg_group force;" under standalone postmaster
> with options -O and -P. You must shutdown postmaster first.
>
> Regards.
>
> Hiroshi Inoue
> Inoue(at)tpf(dot)co(dot)jp
>

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org