Simon Riggs wrote: > The whole point of > wal_level discussion was to avoid needing multiple switches to turn > something on.
No, the point of wal_level was to make the behavior easier to understand, by uncoupling the level of WAL-logging from various other switches, controling it directly and explicitly with a new GUC instead. It added a new switch, but made the system as a whole easier to understand and configure. >> > I can't imagine a situation where "allow connections if the WAL allows >> > it" would be a sensible setting. If there is one, we could have an >> > 'auto' mode, but not as the default. > > I can. Simple, obvious behaviour. Turn it on in the master, works on the > standbys. Yes, but when would you want that? Here's the use cases I can think of: purpose of the standby - do you want hot standby or not? reporting - yes offloading queries from master - yes warm standby for high availability - no offloading taking filesystem-level backups from master - no offloading pg_dump from master - yes 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. When you just want hot standby to be on or off, it's weird to control that from the master. Action at a distance. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
