Re: pg_group_name_index corrupt?

> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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.)

Oh, so it was my indexes on system relations, and because pg_group is a
shared one, there was a problem.

> 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?

Well, pg_group is not used very much. Can we disable the cache from
using the index? I think that would get us out of the problem.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026