Re: [HACKERS] index fix report - Mailing list pgsql-hackers

From David Hartwig
Subject Re: [HACKERS] index fix report
Date
Msg-id 35EEAA99.95D1132B@insightdist.com
Whole thread Raw
In response to index fix report  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers

Thomas G. Lockhart wrote:

> > Did this get resolved?
>
> Yes, a file got left out of the cvs commit; Bruce fixed it right away.
>
> Update:
>
> I'm still seeing problems with the regression tests, and it appears to
> be the same symptom reported by someone else earlier: a couple of tables
> (or indices) exist but something is munged in pg_class so that I can
> only see the entry using a "like" query; an "=" equals query does not
> return the row.

I know why this was happening. (At least on the surface)  In my case,
whenever a I added an index to a table pg_class_relname_index was getting
corrupted.  The nature of  the corruption was that any query that used the
pg_class_relname_index to find a table that was just indexed, could no
longer find it.   The corruption must occur on the update of pg_class when
the index is added.  This explains why:

        CREATE TABLE foo (i int);
        CREATE INDEX foo_idx ON foo USING btree(i);

        SELECT * FROM pg_class;

    Showed a complete correct list of tables.

         SELECT * FROM pg_class WHERE = 'foo';
                and
         SELECT * FROM pg_class WHERE LIKE 'foo%';

    Showed nothing.   I did not know LIKE was using an index.   It through
me.  Nice job by sombody.

        SELECT * FROM pg_class WHERE LIKE '%foo';

    Showed my original table.  But this query like the first does a full
scan.


In any case I will be doing some testing myself this afternoon.





pgsql-hackers by date:

Previous
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] Adding PRIMARY KEY info
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] Adding PRIMARY KEY info