On 09.08.2012 19:39, Robert Haas wrote:
> On Thu, Aug 9, 2012 at 9:09 AM, Heikki Linnakangas
> <heikki.linnakangas@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