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