On Fri, Jan 28, 2011 at 8:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
In response to
- Re: FPI at 2011-01-28 20:08:44 from Tom Lane
pgsql-hackers by date
|Next:||From: Kevin Grittner||Date: 2011-01-31 15:31:18|
|Subject: Re: Error code for "terminating connection due to conflict with recovery"|
|Previous:||From: Hitoshi Harada||Date: 2011-01-31 15:07:19|
|Subject: Re: Add ENCODING option to COPY|