Re: [HACKERS] index fix report

In message <35EEA3A6.8E9270F7@alumni.caltech.edu>, "Thomas G. Lockhart" writes:
> > 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.
>
> This may only happen with tables which have been destroyed and then
> redefined??
>
> I've done a full "cvs update -Pd", a "make distclean", and an initdb.
> I'll try a clean checkout next. If that doesn't help, then will start
> poking at it...
>
>                      - Tom
>

I just did a cvs update, and ran the regression test on solaris.

I think what Tom is describes is my only remaining problem.
Tables just appear to "vanish".  For instance this is from the
triggers test:

QUERY: create table pkeys (pkey1 int4 not null, pkey2 text not null);
QUERY: create table fkeys (fkey1 int4, fkey2 text, fkey3 int);
QUERY: create table fkeys2 (fkey21 int4, fkey22 text, pkey23 int not null);
QUERY: create index fkeys_i on fkeys (fkey1, fkey2);
QUERY: create index fkeys2_i on fkeys2 (fkey21, fkey22);
QUERY: create index fkeys2p_i on fkeys2 (pkey23);
ERROR:  DefineIndex: fkeys2 relation not found

Odd that it works the first time.  The triggers test later crashes.

I also had this at to top of sanity_check:

QUERY: VACUUM;
NOTICE:  Index pg_class_relname_index: NUMBER OF INDEX' TUPLES (169) IS NOT THE SAME AS HEAP' (139)
NOTICE:  Index pg_class_oid_index: NUMBER OF INDEX' TUPLES (169) IS NOT THE SAME AS HEAP' (139)
NOTICE:  Rel pg_trigger: Uninitialized page 0 - fixing


All in all *much* better!

Thanks,

Tom Szybist
szybist@boxhill.com