Re: Suggestions for post-mortem...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Suggestions for post-mortem...
Date: 2006-01-25 16:18:44
Message-ID: 1429.1138205924@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner <pjw(at)rhyme(dot)com(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2006-01-25 16:21:57 Re: Cleaning up the INET/CIDR mess
Previous Message Peter Eisentraut 2006-01-25 15:32:34 Re: [PATCHES] Adding a --quiet option to initdb