Re: Patch for fail-back without fresh backup

On Fri, Oct 25, 2013 at 5:57 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> 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:
>>
>> 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.
>

+1.

Many user would not realize that it is too late If we will provide it
as additional GUC.
And I agree with writing log including the block number of the changed block.
I think that writing log is not lead huge overhead increase.
Is those WAL record replicated to the standby server in synchronous (
of course when configuring sync replication)?
I am concerned that it lead performance overhead with such as
executing SELECT or auto vacuum. especially, when two servers are in
far location.

Regards,

-------
Sawada Masahiko