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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Hannu Krosing <hannu(at)skype(dot)net>
Subject: Re: Is full_page_writes=off safe in conjunction with PITR?
Date: 2006-04-17 19:00:58
Message-ID: 4129.1145300458@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-04-17 19:06:28 Re: Is full_page_writes=off safe in conjunction with PITR?
Previous Message Stephen Frost 2006-04-17 17:59:48 Re: A successor for PQgetssl