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(?)
Re: WAL replay failure after file truncation(?) |
Список | 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 по дате отправления: