Re: Patch for fail-back without fresh backup

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch for fail-back without fresh backup
Date: 2013-10-24 20:57:29
Message-ID: CABUevEwigM-pPoBKGdkm6LZyO+OVrdz7sOXN_5By8e8PcaE3sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 24, 2013 at 10:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> 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.

+1 on the principle.

In fact I've been considering suggesting we might want to retire the
difference between archive and hot_standby as wal_level, because the
difference is usually so small. And the advantage of hot_standby is in
almost every case worth it. Even in the archive recovery mode, being
able to do pause_at_recovery_target is extremely useful. And as you
say in (c) above, many users don't realize that until it's too late.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-10-24 21:36:13 Re: Location for external scripts for Extensions?
Previous Message Robert Haas 2013-10-24 20:53:17 Re: Reasons not to like asprintf