Re: [HACKERS] index fix report

In message <35EEA3A6(dot)8E9270F7(at)alumni(dot)caltech(dot)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(at)boxhill(dot)com