pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: Robert Haas on 29 Apr 2010 09:16 On Thu, Apr 29, 2010 at 9:00 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Robert Haas wrote: >> On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas >> <heikki.linnakangas(a)enterprisedb.com> wrote: >>> Robert Haas wrote: >>>> I kind of agree with Simon on this one, except I would probably choose >>>> to have just on and off and make on work like his auto. >>>> >>>> In other words, recovery_connections=on means, give me recovery >>>> connections if possible, otherwise don't worry about it. >>> If you're setting up a reporting server, and hot standby can't start, >>> the server is not functioning properly. I would like to get an error in >>> that case. >> >> Presumably you will actually try connecting to it, no? > > Sure. I guess it would be acceptable if 'on' meant 'on, if possible', as > long as 'off' is the default. Otherwise it's too surprising. I disagree. I think on should mean 'on, if possible' and 'on' should be the default. I think that's how it was before this round of changes - but maybe I'm mistaken? It seems like it makes sense, at any rate. ....Robert -- 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: Robert Haas on 29 Apr 2010 09:16 On Thu, Apr 29, 2010 at 9:07 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Robert Haas wrote: >> How about this one? The administrator sets up a master and a slave. >> She's heard about this new Hot Standby feature and so decides to >> enable it on the slave just to play around with it. Subsequently, she >> takes a better job at another company and they hire a new >> administrator, who thinks the Hot Standby WAL may be causing a >> performance problem on the master, so he switches wal_mode to archive. >> Six months later the primary fails. > > Umm, I don't see the problem. For high availability purposes, the > standby works just as well with wal_mode='archive'. Or are you saying > that the standby was configured with recovery_connections='on', and > failed to start for those six months because hot standby could not be > enabled, and no-one noticed? Yep. ....Robert -- 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: Tom Lane on 29 Apr 2010 09:48 Simon Riggs <simon(a)2ndQuadrant.com> writes: > recovery_connections was on by default and unanimous agreement until > recently and I don't want to change that now, Uh, it was on by default only because a lot of us hadn't noticed that. I agree with Heikki's position here: it should not be on by default. regards, tom lane -- 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: Tom Lane on 29 Apr 2010 13:03 Robert Haas <robertmhaas(a)gmail.com> writes: > Nobody is proposing otherwise. What Simon and I are proposing is that > if the master is configured to support HS, it comes up on the slave by > default without requiring additional configuration. Now maybe that's > too much spooky action at a distance, but I suspect it IS the behavior > most people will want. If Tom and Heikki get their way and change the > default behavior, it'll just mean (nearly) everyone flips one extra > configuration switch. We already bought into the "one extra switch" penalty when we agreed to invent a separate wal_level parameter. The entire point of that was to have more, but simpler-to-understand, parameters with fewer hidden interactions. Arguing that there are now too many knobs to twiddle amounts to trying to revisit that discussion, which we don't have time for now. >> That said, I'ld probalby be happy with PG 9 having a "default" config >> of: >> � � � �wal_mode = hot_standby >> � � � �recovery_connections = on > That would be a bad idea - there's a significant performance penalty > from setting wal_level to anything other than minimal (just as there > is for turning on archive_mode in 8.4). There is not only a performance penalty, but a reliability penalty. Enabling these switches turns on a whole lot of code that, with all due respect to those who have worked on it, is absolutely positively guaranteed to be full of bugs. Not all of which are going to be flushed out during beta. If we ship 9.0 with these things on by default, it will result in an immediate reliability downgrade for installations that are simply doing what they did before and not even interested in HS/SR. Maybe by 9.1 or 9.2 it would be sensible to have some of this code turned on by default. But it is absolutely not in keeping with this project's mindset or historical practice to enable it by default now. regards, tom lane -- 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: "Kevin Grittner" on 29 Apr 2010 13:16
Simon Riggs <simon(a)2ndQuadrant.com> wrote: > Which is what everybody has requested. You continue to use the term "everybody" rather loosely. I don't begrudge people features they want, even when *I* don't need them; but please don't take my lack of argument against adding this feature as a silent request for it. SR has a place in our shop, especially if it can create traditional WAL file segments on the receiving end. (I understand that will not be a built-in feature for 9.0, but perhaps there will be a pgfoundry project or some such.) HS is no use to us, and I would rather not pay a performance penalty or take the risks of exercising complex new code paths because others need it. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |