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 по дате отправления: