Re: WAL replay failure after file truncation(?)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL replay failure after file truncation(?)
Дата
Msg-id 2925.1117059559@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL replay failure after file truncation(?)  (Manfred Koizar <mkoi-pg@aon.at>)
Ответы Re: WAL replay failure after file truncation(?)  (Manfred Koizar <mkoi-pg@aon.at>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Source Code Help Needed
Следующее
От: Jaime Casanova
Дата:
Сообщение: adding a function to pg_proc.h