Re: pg_group_name_index corrupt? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_group_name_index corrupt?
Date
Msg-id 28775.957476941@sss.pgh.pa.us
Whole thread Raw
In response to RE: pg_group_name_index corrupt?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: pg_group_name_index corrupt?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_group_name_index corrupt?  (The Hermit Hacker <scrappy@hub.org>)
Re: pg_group_name_index corrupt?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> Why does pg_group exist under $PGDATA though the indexes exist
> under each $PGDATA/base/db_name ?
> Could it be consistent on all databases ?

Oh my, I think you've got it!  The indexes must be SharedSystemRelations!!

Backend 1 in database regression:

regression=# vacuum analyze pg_group;
VACUUM

Backend 2 in database other is also happy:

other=# vacuum analyze pg_group;
VACUUM

Now create a group with backend 1:

regression=# create group g;
CREATE GROUP

Backend 1 sees the index entries:

regression=# vacuum analyze pg_group;
VACUUM

But backend 2 doesn't:

other=# vacuum analyze pg_group;
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.
VACUUM

pg_shadow would have the same problem if it had indices, which I thought
it did but they seem to have been disabled.

Can you say "one more initdb"?  I knew you could...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: pg_group_name_index corrupt?
Next
From: Tom Lane
Date:
Subject: Re: pg_group_name_index corrupt?