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
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 |