Re: Is full_page_writes=off safe in conjunction with PITR? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Is full_page_writes=off safe in conjunction with PITR?
Date
Msg-id 200604171906.k3HJ6Sd01622@candle.pha.pa.us
Whole thread Raw
In response to Re: Is full_page_writes=off safe in conjunction with PITR?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is full_page_writes=off safe in conjunction with PITR?
Next
From: "Jim C. Nasby"
Date:
Subject: CVS tags