Re: [HACKERS] Broken PostgreSQL (latest CVS) - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Broken PostgreSQL (latest CVS) |
Date | |
Msg-id | 199808201523.LAA24892@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] Broken PostgreSQL (latest CVS) (jwieck@debis.com (Jan Wieck)) |
List | pgsql-hackers |
> > > > Hi hackers. > > > > I grabbed the latest CVS from this morning and did a clean build > > and initdb. > > > > Things look a little broken as I get a SIGSEGV when trying to > > create a table. > > I noticed them too (but I thought it was a flaw since they > where gone (up to now) after a 'make install' and 'initdb'). > > > > > Any idea what went wrong? > > > > Keith. > > > > Program received signal SIGSEGV, Segmentation fault. > > 0xe016e6b4 in _wordcopy_fwd_aligned () > > (gdb) bt > > #0 0xe016e6b4 in _wordcopy_fwd_aligned () > > #1 0xe011d62c in memmove () > > #2 0x26ad0 in DataFill (data=0x1af964 "", tupleDesc=0x4, value=0xefffce3c, > > nulls=0xefffce40 "", infomask=0xefffcbc6, bit=0x1af958 "\003") > > at heaptuple.c:208 > > #3 0x27abc in index_formtuple (tupleDescriptor=0x15b710, value=0xefffce3c, > > null=0xefffce40 "") at indextuple.c:78 > > Looks like the tuple desctiptor given to index_formtuple() is > corrupted somewhere before the call to memmove() in > DataFill() line 208. > > I think it must have happened inside of DataFill() or > something DataFill() called, because at the time of failure, > the on-stack variable tupleDescriptor of index_formtuple() > looks still good - so I assume index_formtuple() handed the > correct value to DataFill() at line 78 and it has been > corrupted after. > > BTW: I love gdb. OK, I have just applied another patch to fix the problem I was seeing with vacuum analyze. The problem was in catalog/index.c::UpdateStats(). First, this was being called during initialization, but was using the cache. I had to put an IsBootstrapProcessingMode() test, and add a sequential scan. Second, there was no WriteBuffer() after the modification of the record, and that caused problems. I assume the old code was so kludgy that they somehow got the block written by accident. The manifestation of the problem was the at the pg_class.relhasindex record was not being set, and therefore the pg_description index was not getting updated, and vacuum was complaining. Adding syscache calls is tricky because it is hard to know if a function is called during bootstrap. Please do a clean compile and new initdb, and let me know if anyone has any more problems. I still have the patch file I used, and have consulted it to see what the cause it. In this case, there never was a WriteBuffer() call where it should have been. It is possible there is some other missing code that has been tickled by my changes. initdb runs fine here now under BSDI. Of course, it ran fine earlier too, with just the vacuum analyze problem. -- 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)
pgsql-hackers by date: