Re: FPI - Mailing list pgsql-hackers

From Greg Stark
Subject Re: FPI
Date
Msg-id AANLkTi=Jn5LhReTgLuNMUcgf8uBhmw_W5ciULj4pjdo-@mail.gmail.com
Whole thread Raw
In response to Re: FPI  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jan 28, 2011 at 8:08 PM, Tom Lane <tgl@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


pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: Add ENCODING option to COPY
Next
From: Heikki Linnakangas
Date:
Subject: Re: Spread checkpoint sync