pgsql: Make CheckRequiredParameterValues()depend upon correct
in [PgSql]
|
From: Heikki Linnakangas on 29 Apr 2010 12:55 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 29 Apr 2010 13:57 Simon Riggs wrote: > Can we keep the default=on during beta and collect evidence before > making a final decision at release? That's tempting to get more (inadvertent) testing of HS, but I don't think it would be fair to the beta testers. The expectation is that what's in beta is what's in the release, unless some new issue pops up. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 29 Apr 2010 14:27 Simon Riggs wrote: > On Thu, 2010-04-29 at 19:55 +0300, Heikki Linnakangas wrote: >> It's safer to run >> with recovery_connections off if you don't need the feature. > > Presumably your advice is also that people should not run with Streaming > Replication if they don't need that feature? Umm, yes. Why would you bother to set it up if you don't need it? > And that we should also > have an enable_joinremoval flag so the risk it poses can be minimized? > You didn't argue this way with regard to vacuum/FSM in 8.4, which was > much more critical; we're just talking about a standby server. This is getting bizarre... I wasn't really following the join removal discussions, but it seems much safer and less complex. And it would not have been feasible to have both implementations of FSM around and have the user to choose. I have been relieved by the lack of bug reports on the new FSM, that was a big change that impacted all installations. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 Prev: Differential backup Next: pgsql: MakeCheckRequiredParameterValues() depend upon correct |