Re: Suggestions for post-mortem... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Suggestions for post-mortem...
Date
Msg-id 1429.1138205924@sss.pgh.pa.us
Whole thread Raw
In response to Suggestions for post-mortem...  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Suggestions for post-mortem...  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> We just had a DB die quite nastily, and have no clear idea why.

Define "die quite nastily" ... you haven't really said what went wrong.

> 2006-01-25 12:25:31 EST [mail,5017]: ERROR:  failed to fetch new tuple
> for AFTER trigger
> 2006-01-25 12:26:01 EST [mail,93689]: WARNING:  index "XXXX_pkey"
> contains 1416 row versions, but table contains 1410 row versions
> 2006-01-25 12:26:01 EST [mail,93689]: HINT:  Rebuild the index with REINDEX.
> 2006-01-25 12:26:01 EST [mail,93689]: WARNING:  index "YYYY" contains
> 1416 row versions, but table contains 1410 row versions

> ...repeated several times for several indexes of the same table.

These could all be manifestations of the ReadBuffer bug fixed in 8.0.6.
Tickling that bug would result in zeroing out a recently-added table page,
which would result in (a) more index entries than table entries, and
(b) possible bleating from other processes wondering where their freshly
inserted tuples went.  Seems to square with the facts presented,
especially if the indexes all agree on how many tuples there should be
--- that makes it pretty unlikely that index corruption is the cause.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] Adding a --quiet option to initdb
Next
From: Greg Stark
Date:
Subject: Re: Cleaning up the INET/CIDR mess