Re: WAL replay failure after file truncation(?)

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: WAL replay failure after file truncation(?)
Дата
Msg-id bti991h21npmmc73akqkbpqnlhst5fugon@4ax.com
обсуждение исходный текст
Ответ на WAL replay failure after file truncation(?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WAL replay failure after file truncation(?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WAL replay failure after file truncation(?)  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Wed, 25 May 2005 11:02:11 -0400, Tom Lane <tgl@sss.pgh.pa.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).

ServusManfred



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

Предыдущее
От: Vikram Kalsi
Дата:
Сообщение: Source Code Help Needed
Следующее
От: Manfred Koizar
Дата:
Сообщение: Re: Cost of XLogInsert CRC calculations