Re: WAL replay failure after file truncation(?)

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WAL replay failure after file truncation(?)
Date: 2005-05-25 19:24:24
Message-ID: bti991h21npmmc73akqkbpqnlhst5fugon@4ax.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 25 May 2005 11:02:11 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).

Servus
Manfred

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Koizar 2005-05-25 19:24:59 Re: Cost of XLogInsert CRC calculations
Previous Message Vikram Kalsi 2005-05-25 18:50:38 Source Code Help Needed