Re: [WIP] Performance Improvement by reducing WAL for Update Operation

On Thu, Aug 9, 2012 at 9:09 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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.

No?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company