From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Suggestions for post-mortem... |
Date: | 2006-01-27 00:09:15 |
Message-ID: | 43D964AB.7020906@rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Define "die quite nastily" ... you haven't really said what went wrong.
>
We lost data from this table, and ended up with transactions rolled back
that were in fact committed (ie. data was in DB, program code thought
they were rolled back).
End result was we deemed the database to be in an unknown, uncorrectable
and unstable state.
> 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.
This sounds consistent, I'd guess the 80 missing records correspond to
80 most recently updated. Not sure about the missing user -- I'll see
what I can find.
Thanks for the help -- we now have a probable cause, and a way forward.
Alvaro Herrera wrote:
> Can you confirm how long does the vacuum take to run?
Usually very quick, runs every minute -- so the problem occurred between
the two vacuums.
> isolated to this one table, or does it manifest somewhere else? Do you
> have other errors that may indicate a hardware problem?
>
No.
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2006-01-27 01:03:25 | Proposal: new pg_dump options --copy-delimiter and --copy-null |
Previous Message | Tom Lane | 2006-01-26 23:40:08 | A note about testing EXEC_BACKEND on recent Linuxen |