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
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 |