Re: pg_group_name_index corrupt?

> "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!!

Yup, Hiroshi has spotted the problem.  Turning the indexes on pg_group
into shared relations fixes the cross-database misbehavior shown in my
prior message, and I'll bet this bug explains Marc's report too.

We never had any indexes on pg_group (or any shared relation) before,
which is why we hadn't seen this kind of failure before.  (Another
limitation of the regression tests exposed --- they don't test
cross-database behaviors.)

So, now what?  This is a simple fix, but it will require initdb (or at
least pg_upgrade), which I'd really rather not do at this point in the
release cycle.  But I'm not sure we have any choice.  As it stands,
pg_group is broken.

If we are going to have to force a new initdb here, we probably ought
to reconsider a couple of recent past decisions that were put off on
grounds of "we don't want another initdb before 7.0".  I'm thinking of
the remaining ODBC support functions and the new LIKE estimator in
particular.  Do we want to revisit those decisions, or leave well enough
alone?
        regards, tom lane