Re: pg_group_name_index corrupt?

On Thu, 4 May 2000, Tom Lane wrote:

> > "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.)
>
> 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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org