Re: FPI

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: FPI
Date: 2011-01-31 15:10:43
Message-ID: AANLkTi=Jn5LhReTgLuNMUcgf8uBhmw_W5ciULj4pjdo-@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
that block.

--
greg

In response to

  • Re: FPI at 2011-01-28 20:08:44 from Tom Lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-01-31 15:31:18 Re: Error code for "terminating connection due to conflict with recovery"
Previous Message Hitoshi Harada 2011-01-31 15:07:19 Re: Add ENCODING option to COPY