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. No? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
