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

From Tom Lane
Subject Re: WAL replay failure after file truncation(?)
Date
Msg-id 2925.1117059559@sss.pgh.pa.us
Whole thread Raw
In response to Re: WAL replay failure after file truncation(?)  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: WAL replay failure after file truncation(?)
List pgsql-hackers
Manfred Koizar <mkoi-pg@aon.at> writes:
> 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?

We don't *have* the contents ... that's exactly why it's panicking ...

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

That seems like a good idea --- it covers the problem, and what's more,
it won't complain until after it finishes replay.  Which means that if
you do get the PANIC, you can get out of it with pg_resetxlog and not
need to worry that you are throwing away whatever good data is available
from the WAL log.  (This assumes that we go ahead and checkpoint out
the working buffers before we make the check for empty list.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Source Code Help Needed
Next
From: Jaime Casanova
Date:
Subject: adding a function to pg_proc.h