Heikki Linnakangas <hlinnakan...@vmware.com> writes:
> The problem we're trying to solve is determining how much WAL needs to
> be replayed until the database is consistent again. In crash recovery,
> the answer is "all of it". That's why the CRC in the WAL is essential;
> it's required to determine where the WAL ends. But if we had some other
> mechanism, like if we updated minRecoveryPoint after every XLogFlush()
> like Simon suggested, we wouldn't necessarily need the CRC to detect end
> of WAL (not that I'd suggest removing it anyway), and we could throw an
> error if there is corrupt bit somewhere in the WAL before the true end
> of WAL.
Meh. I think that would be disastrous from both performance and
reliability standpoints. (Performance because the whole point of WAL is
to commit with only one disk write in one place, and reliability because
of greatly increasing the number of writes to the utterly-critical
pg_control file.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
