Re: WAL replay failure after file truncation(?) - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: WAL replay failure after file truncation(?)
Date
Msg-id bti991h21npmmc73akqkbpqnlhst5fugon@4ax.com
Whole thread Raw
In response to WAL replay failure after file truncation(?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WAL replay failure after file truncation(?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WAL replay failure after file truncation(?)  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Wed, 25 May 2005 11:02:11 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>Plan B is for WAL replay to always be willing to extend the file to
>whatever record number is mentioned in the log, even though this
>may require inventing the contents of empty pages; we trust that their
>contents won't matter because they'll be truncated again later in the
>replay sequence.

Another idea: WAL replay does not apply changes to nonexistent blocks,
but it keeps a list (hash table, file, whatever) of those blocks.
When a truncate WAL record is found, all entries for blocks affected
by the truncation are removed from the list.  Is it sufficient to
remember just the relation and the block number or do we need the
contents a well?

If the list is non-empty at the end of WAL replay, this is evidence of
a serious problem (file system corruption or Postgres bug).

ServusManfred



pgsql-hackers by date:

Previous
From: Vikram Kalsi
Date:
Subject: Source Code Help Needed
Next
From: Manfred Koizar
Date:
Subject: Re: Cost of XLogInsert CRC calculations