Re: Is full_page_writes=off safe in conjunction with PITR?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Is full_page_writes=off safe in conjunction with PITR?
Дата
Msg-id 200604171906.k3HJ6Sd01622@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Is full_page_writes=off safe in conjunction with PITR?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> 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.

Great, yea, checkpoing syncs up the dirty buffers with the file system,
and it is true we need that to happen before the backup begins.

The idea of creating functions to mark start/stop of backup has clearly
been a win here.

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Is full_page_writes=off safe in conjunction with PITR?
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: CVS tags