On Fri, Jan 28, 2011 at 8:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 3. Page LSN > WAL location: do NOT apply field update or change LSN. >
I don't think this works. There could be multiple writes to a page for different records before the crash occurs. The LSN could be far in the future and yet still have a torn page missing the update. Another thing to consider is that there's still a plan on the table to implement block checksums. Does any of this block that? Or do checksums make it *easier* to implement any of this? You can check the checksum and if it's valid assume there isn't a torn page. If the LSN >= current you can skip the log record. If the checksum is invalid you could try replaying the log entry and if it makes it valid then you're golden. If not then you could continue and hopefully there will be more unconditional records and eventually the block will become consistent or a FP write will come along later. Just for reference the Oracle solution is to ignore the problem but provide recovery tools to recover an individual block. You go to the last consistent backup, pull the old version of the block from there, then apply the logs from that point forward replaying any records for that block. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
