> > "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.)
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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
