On Thu, 4 May 2000, Tom Lane wrote:
> > "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?
Leave well enough alone ... this fixed, IMHO, a *very* important potential
bug, whereas the other two can be worked around. AT this *really* late
stage in the cycle, fixing one bug at least only opens us up to the
possibility of one bug ... doing the ODBC/LIKE stuff aren't mission
critical, and really only affect a relatively small group of ppl in
comparison ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
