Re: Is full_page_writes=off safe in conjunction with PITR?
От | Tom Lane |
---|---|
Тема | Re: Is full_page_writes=off safe in conjunction with PITR? |
Дата | |
Msg-id | 4129.1145300458@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Is full_page_writes=off safe in conjunction with PITR? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Is full_page_writes=off safe in conjunction with PITR?
Re: Is full_page_writes=off safe in conjunction with PITR? |
Список | pgsql-hackers |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Tom Lane wrote: >> If we were to do this, I'd want some more-bulletproof mechanism for >> forcing full_page_writes on during the backup. We could probably >> keep a "backup in progress" flag in shared memory, and examine that >> along with the GUC variable before deciding to omit a full-page write. > Yes, good point. The setting has to be seen by all backends at the same > time, so yea, a shared memory variable seems required. I've applied a patch for this. On reflection, the CHECKPOINT during pg_start_backup was actually necessary for torn-page safety even without full_page_writes off. The reason is that the torn-page risk occurs when we write a page from shared memory, not when we modify it in memory. Without a CHECKPOINT, a page modified just before pg_start_backup could be dumped during the backup and then be saved in a torn state, even though no WAL record for it is emitted anytime during the backup procedure. So that comment's been wrong all along. regards, tom lane
В списке pgsql-hackers по дате отправления: