Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct |
Дата | |
Msg-id | 4BD96388.8070203@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Make
CheckRequiredParameterValues() depend upon correct
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: