Re: pg_group_name_index corrupt?

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