Re: Patch for fail-back without fresh backup - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Patch for fail-back without fresh backup
Date
Msg-id 52698868.2070907@agliodbs.com
Whole thread Raw
In response to Re: Patch for fail-back without fresh backup  (Sawada Masahiko <sawada.mshk@gmail.com>)
Responses Re: Patch for fail-back without fresh backup
Re: Patch for fail-back without fresh backup
List pgsql-hackers
On 10/24/2013 01:14 PM, Heikki Linnakangas wrote:
> One extra WAL record whenever a hint bit is set on a page, for the first
> time after a checkpoint. In other words, a WAL record needs to be
> written in the same circumstances as with page checksums, but the WAL
> records are much smaller as they don't need to contain a full page
> image, just the block number of the changed block.
> 
> Or maybe we'll write the full page image after all, like with page
> checksums, just without calculating the checksums. It might be tricky to
> skip the full-page image, because then a subsequent change of the page
> (which isn't just a hint-bit update) needs to somehow know it needs to
> take a full page image even though a WAL record for it was already written.

I think it would be worth estimating what this actually looks like in
terms of log write quantity.  My inclication is to say that if it
increases log writes less than 10%, we don't need to provide an option
to turn it off.

The reasons I don't want to provide a disabling GUC are:
a) more GUCs
b) confusing users
c) causing users to disable rewind *until they need it*, at which point
it's too late to enable it.

So if there's any way we can avoid having a GUC for this, I'm for it.
And if we do have a GUC, failback should be enabled by default.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Patch for fail-back without fresh backup
Next
From: Robert Haas
Date:
Subject: Re: Reasons not to like asprintf