Re: 9.2.3 crashes during archive recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.2.3 crashes during archive recovery
Date: 2013-02-13 19:37:44
Message-ID: 11565.1360784264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-02-13 19:40:23 Re: 9.2.3 crashes during archive recovery
Previous Message Daniel Farina 2013-02-13 19:34:02 Re: Fractal tree indexing