On 9 May 2013 23:13, Greg Stark <st...@mit.edu> wrote: > On Thu, May 9, 2013 at 10:45 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On 9 May 2013 22:39, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Simon Riggs <si...@2ndquadrant.com> writes: >>>> If the current WAL record is corrupt and the next WAL record is in >>>> every way valid, we can potentially continue. >>> >>> That seems like a seriously bad idea. >> >> I agree. But if you knew that were true, is stopping a better idea? > > Having one corrupt record followed by a valid record is not an > abnormal situation. It could easily be the correct end of WAL.
I disagree, that *is* an abnormal situation and would not be the "correct end-of-WAL". Each WAL record contains a "prev" pointer to the last WAL record. So for the next record to be valid the prev pointer would need to be exactly correct. > However it is possible to reduce the window. Every time the > transaction log is synced a different file can be updated with the a > known minimum transaction log recovery point. Even if it's not synced > consistently on every transaction commit or wal sync it would serve as > a low water mark. Recovering to that point is not sufficient but is > necessary for a consistent recovery. That file could be synced lazily, > say, every 10s or something like that and would guarantee that any wal > corruption would be caught except for the last 10s of wal traffic for > example. I think it would be easy enough to have the WALwriter update the minRecoveryPoint once per cycle, after it has flushed WAL. Given the importance of pg_control and its small size, it seems like it would be a good idea to take a backup copy of it every checkpoint to make sure we have that data safe. And have pg_resetxlog keep a copy also every time that is run. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers