On 09.08.2012 19:39, Robert Haas wrote:
On Thu, Aug 9, 2012 at 9:09 AM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
I meant corruption caused by anything, like disk failure, bugs, cosmic rays,
etc. The point is that currently the WAL record contains all the information
required to reconstruct the old tuple. With a diff method, that's no longer
the case, so if the old tuple gets corrupt for whatever reason, that error
will be propagated to the new tuple.
It's not an issue as long as everything works correctly, but some redundancy
is nice when you're trying to resurrect a corrupt database. That's what
we're talking about here. That said, I don't think it's a big deal for this
patch, at least not as long as full-page writes are enabled.
So suppose that the following sequence of events occurs:
1. Tuple A on page 1 is updated. The new version, tuple B, is placed on page 2.
2. The table is vacuumed, removing tuple A.
3. Page 1 is written durably to disk.
4. Crash.
If reconstructing tuple B requires possession of tuple A, it seems
that we are now screwed.
Not with full_page_writes=on, as crash recovery will restore the old
page contents. But you're right, with full_page_writes=off you are screwed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
