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. >
+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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
