Simon Riggs wrote: > On Thu, 2010-04-29 at 11:37 -0400, Aidan Van Dyk wrote: >> It's all about the path of least *suprise*. My "least suprise" would >> have been that a similar config I have now with my PITR slaves would >> pretty much still work, and not suddenly start accepting connections, >> and even worse, at some later date when I've already verified that it >> was doing what I expected with the configuration. > > If people upgrade to 9.0 and then are surprised that the features listed > are actually available, I too would be surprised.
Being available is not the same as being on by default. > There is no big use case for "run with HS turned off". Everybody wants > it on, as long as it works and don't cause problems. So far, there is no > evidence to make anyone think that it would and I wish to avoid that > implication. The use case I explained earlier exists, the one with a master and a warm standby server with pgbouncer in front. And Aidan and me are human beings, included in "everybody". You know that there is cases where it causes problems in the standby, even ignoring the possibility of bugs. For example, if you increase max_connections in the master, the standby will abort. It's safer to run with recovery_connections off if you don't need the feature. > Heikki previously argued strongly against having any switch at all, so > it could be turned on all the time. Nothing's changed. I argued that we should always WAL-log the information required to enable hot standby, on the grounds that the overhead is small. I.e. that wal_level would be a two-state switch, either 'minimal' or 'hot_standby'. But I'm happy with how that is now. But that's not what we're discussing now, don't confuse things. We're talking about recovery_connections, not wal_level. -- 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
