Re: WAL replay failure after file truncation(?)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL replay failure after file truncation(?)
Дата
Msg-id 14785.1117071887@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL replay failure after file truncation(?)  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Список pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: WAL replay failure after file truncation(?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Network write errors (was: Re: Feature freeze date for