On Thu, 2010-04-29 at 13:46 +0300, Heikki Linnakangas wrote:
> purpose of the standby - do you want hot standby or not?
> reporting - yes
> offloading queries from master - yes
> offloading pg_dump from master - yes
These would work using the proposed default.
> warm standby for high availability - no
> offloading taking filesystem-level backups from master - no
These can be explicitly turned off.
You're presuming there is benefit in turning recovery_connections = off,
though it is perfectly valid to do those use cases with it on. There are
many ways to control connections, not just that switch. It will
certainly be easier to monitor the HA system by running queries against
it than not. Do you have any evidence there is benefit in the *typical*
case for turning the setting off?
> All of those either want hot standby, or don't. What use case is there
> for "enabled, if the required information is in the WAL"? If there is
> one, it sure doesn't seem like the most common one.
I think "I want it to just work" is fairly common.
> When you just want
> hot standby to be on or off, it's weird to control that from the master.
> Action at a distance.
That's the proposed default, not the only control. The standby can
override what the master says if it definitely doesn't want it, but is
smart enough to avoid silly configuration errors. Turning off wal_level
on the master *does* affect the standby, so pretending we have a
completely separate configuration option makes no sense for me.
Robert's point when he raised the wal_level discussion was about
reducing the number of parameter settings required to make this work. An
intelligent default will reduce level of configuration and allow us to
make Hot Standby work on the standby, out of the box, and that is worth
having.
-- Simon Riggs www.2ndQuadrant.com