Re: pg_dump error... Follow up

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Adam Witney <awitney(at)sgul(dot)ac(dot)uk>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>, Michael Fuhr <mike(at)fuhr(dot)org>
Subject: Re: pg_dump error... Follow up
Date: 2005-09-08 16:28:55
Message-ID: 7575.1126196935@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> To Tom: could this be caused by a WAL recovery that wrote a page image
> to the wrong table? I guess it is very unlikely because the CRC of the
> WAL record would likely not match, but it's an idea.

I don't see any reason to think that WAL recovery would be more likely
to cause this than normal operation.

If it is a Postgres bug, my thoughts were pointing in the direction of a
race condition that somehow allows the tag (identifier) of a buffer to
be changed before it gets written out. I don't see any way that could
happen ... but given the very small number of reports of such problems
(i.e. 1) it would definitely have to be induced by some really
low-probability event, such as a race condition with a very narrow
window.

Or it might not be our bug. We've certainly seen previous cases in
which either the kernel or the disk drive wrote the wrong data --- it
could be that this is the same thing, only it happened that the "wrong
data" was some other Postgres data that happened to be passing through
the system at about the same time.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2005-09-08 16:47:19 Re: Please help - libpq API
Previous Message Adam Witney 2005-09-08 15:59:27 Re: pg_dump error... Follow up