> Bruce Momjian <maillist@candle.pha.pa.us>
>
> >
> > > (gdb) print attrNums[attOff]
> > > $3 = 15
> > > (gdb) print *hTupDesc
> > > $5 = {natts = 0, attrs = 0x0, constr = 0x0}
> > > (gdb) print fInfo
> > > $6 = (FuncIndexInfo *) 0x0
> > >
> >
> > I believe this is the pg_proc.prosrc index. This is the only case of a
> > system index/cache on a 'text' field, rather than 'name'. 'text' is
> > variable length, unlike the other fields. I wonder if there is some
> > problem with the cache code on this type of index. In 6.3.2, it was
> > there but never used, so it may have been broken all along. This is
> > just a guess, though.
> >
>
> I've just cvs updated and built with -O2 and assert checking.
>
> The automated process actually runs the regression tests at the
> end and gives the following results:-
I just worked with Thomas A. Szybist and telnet'ed into his
Solaris/Sparc machine. We worked through gdb, and found the system
shifting the array values in idesc on the fifth call
to CatalogIndexInsert() while creating a table. The last time through
the for() loop, idesc[2] is null and idesc[1] equals the old value of
idesc[2].
Because recompiling indexing.c with no optimization fixes the problem,
and because gdb is showing idesc[i] getting modified by the for() loop,
I am concluding we have some sort of Sparc gcc optimizer problem. This
code is only slightly modified from the 6.3.2 version, but perhaps
enough to cause the optimizer to get confused.
I tried adding some code to make things clearer for the optimizer but
did not have any luck.
He is going to continue researching the crashes, and perhaps try a newer
gcc.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
