pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: Robert Haas on 29 Apr 2010 13:20 On Thu, Apr 29, 2010 at 1:03 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 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. This is a pretty good argument, and Heikki's argument just upthread that a mismatched max_connections setting could bollix things is an even better one. So I'm now changing my mind and thinking this should be off by default, also. ....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: "Kevin Grittner" on 29 Apr 2010 14:01 Simon Riggs <simon(a)2ndQuadrant.com> wrote: > I've asked for evidence that recovery is any slower as a result of > HS. Can you quantify the impact on the number of bytes written to WAL when switching from the archiving level to the hot standby level? -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
From: Tom Lane on 29 Apr 2010 14:13 Simon Riggs <simon(a)2ndQuadrant.com> writes: > Can we keep the default=on during beta and collect evidence before > making a final decision at release? I'd be for doing that if it didn't have adverse effects on the use of pg_start_backup (which is where we started this thread). But it would be to get more testing, not because we would consider beta results as even possibly giving sufficient confidence to justify shipping 9.0.0 with the default = on. I realize that you've sweated blood over a long period to get this stuff in there, and if I were you I'd probably be wishing it could be on by default too. But from a project management standpoint it's just way too risky to even consider. HS/SR at this point have to be seen as being about as trustworthy as the Windows port was in 8.0.0. No DBA is going to be happy with that stuff getting turned on unless he specifically asks for it. Maybe in 9.1 or 9.2, but not in 9.0. 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: Heikki Linnakangas on 29 Apr 2010 14:34 Simon Riggs wrote: > What Heikki hasn't said is that setting max_prepared_transactions > incorrectly has always caused a fatal error at failover, and still does > so now when HS is disabled. Hmm, good point. That should probably be documented somewhere. Now that we WAL-log the max_prepared_xacts value, I suppose we could throw a WARNING too. > If these concerns were real ones, then that > situation would not have existed for years and would not still do so. There's very few people using two-phase commit out there, and even less so in a standby configuration. I wouldn't draw any conclusions from that. -- 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: Tom Lane on 29 Apr 2010 14:44
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Simon Riggs <simon(a)2ndQuadrant.com> wrote: >> 9.0 without HS enabled is fairly untested on the standby, so it's >> not clear to me turning it off makes you any safer. > I think you've just made the strongest possible case for not > defaulting it on during beta testing. Yes. If we've had it on so far, flipping it at the start of beta seems sensible from a test coverage standpoint. We will certainly have a reasonable number of beta testers who are interested in the feature and turn it on to test it; but we need to make sure the "off" position isn't accidentally broken. 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 |