From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WAL replay failure after file truncation(?) |
Date: | 2005-05-26 01:44:47 |
Message-ID: | 14785.1117071887@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> 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. This seems pretty messy though, especially for
>> indexes. The major objection to it is that it gives up error detection
>> in real filesystem-corruption cases: we'll just silently build an
>> invalid index and then try to run with it. (Still, that might be better
>> than refusing to start; at least you can REINDEX afterwards.)
> You could at least log some sort of warning during the PITR process.
> Anyone running a PITR not paying attention to their logs is in trouble
> anyway...
I'm more worried about the garden variety restart-after-power-failure
scenario. As long as the postmaster starts up, it's unlikely people
will inspect the postmaster log too closely. I think we have a choice
of PANICking and refusing to start, or assuming that no one will notice
that we did something dubious.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-26 01:52:30 | Re: Network write errors (was: Re: Feature freeze date for |
Previous Message | Christopher Kings-Lynne | 2005-05-26 01:38:34 | Re: WAL replay failure after file truncation(?) |