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:

Previous
From: Silvestre Dorador
Date:
Subject: (no subject)
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Broken PostgreSQL (latest CVS)