On Fri, Oct 25, 2013 at 5:57 AM, Magnus Hagander <mag...@hagander.net> wrote:
> On Thu, Oct 24, 2013 at 10:51 PM, Josh Berkus <j...@agliodbs.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.


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.


Sawada Masahiko

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to