Re: [HACKERS] initdb problem

>
> Hi all,
>
> I don't know if this is really related to the initdb problem
> discussion (haven't followed it enough). But seems so because
> it fixes a damn problem during index tuple insertion on
> CREATE TABLE into pg_attribute_relid_attnum_index.
>
> Anyway - this bug was really hard to find. During startup the
> relcache reads in some prepared information about index
> strategies from a file and then reinitializes the function
> pointers inside the scanKey data. But for sake it assumed
> single attribute index tuples (hasn't that changed recently).
> Thus not all the strategies scanKey entries where initialized
> properly, resulting in invalid addresses for the btree
> comparision functions.
>
> With the patch at the end the regression tests passed
> excellent except for the sanity_check that crashed at vacuum
> and the misc test where the select unique1 from onek2 outputs
> the two rows in different order.
>
> Bruce, could you please apply it?
Jan, this is great. It would have taken me a long time to find this.
Why my platform did not fail is a real mystery.

Patch applied. I am looking at the vacuum problem now.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)