pgsql: Make CheckRequiredParameterValues() depend upon correct
in [PgSql]
|
From: Tom Lane on 28 Apr 2010 10:19 Simon Riggs <simon(a)2ndQuadrant.com> writes: > On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote: >> * renamed wal_mode to wal_level > I'm wondering whether this should be a list rather than an enum? If we > add something in the future that adds more info to WAL but doesn't fit > the one-dimensional model this implements then we could be in trouble. > Should this be > e.g. wal_xxxx = feature2, feature3 > e.g. wal_xxxx = feature3 > e.g. wal_xxxx = feature1 I'm a bit suspicious of going in this direction, mainly because DateStyle has been such a PITA over the years. It's not always obvious to users whether adding or removing an item in a list causes something to turn on or off. In any case, the project's expectations for forward compatibility of postgresql.conf settings have always been very low. I don't think we should try to design wal_mode to solve future problems, just the ones we are faced with right now. If it gets changed to look completely different in some future version, that's not a problem. 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: Fujii Masao on 28 Apr 2010 22:33 On Thu, Apr 29, 2010 at 1:14 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Ok, I've finally committed the patch, using wal_level as the name of the > GUC. > ! if (InArchiveRecovery && XLogRequestRecoveryConnections) > ! { > ! if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY) > ! ereport(ERROR, > ! (errmsg("recovery connections cannot start because wal_level was not set to 'hot_standby' on the WAL source server"))); I still have the complaint against the above check. Since the default value of recovery_connections is TRUE, the users who need only archiving not replication (i.e., wal_level is set to 'archive') are likely to often see the failure of the archive recovery by the above check. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 07:15 On Thu, Apr 29, 2010 at 5:55 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: >> The most sensible way is to make the default act intelligently depending >> upon what it finds in the control file. If WAL contains hot_standby >> info, then recovery_connections should be on by default, though can be >> turned off explicitly if required. If WAL does not contain hot_standby >> info we then we throw a WARNING and continue as if recovery_connections >> = off, or if recovery_connections is specified explicitly then we should >> throw an ERROR so that the user knows it won't be possible to use this. >> I think that means we'd need to change recovery_connections to have 2 or >> 3 values, but non-boolean: >> recovery_connections = auto (default) | off >> or >> recovery_connections = auto (default) | on | off >> > > Seems overly complicated. It would be simpler to just set it 'off' by > default. 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. I'd rather not have to change the default to recovery_connections=off - that's one more parameter someone has to set properly. ....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 07:51 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? And what happens when someone changes the setting on the master from hot_standby back to archive? I'd rather have the reporting server continue recovery without being able to accept connections rather than die in its tracks. I think this is a problem that should be solved by monitoring, rather than by automatically taking the server down. ....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 08:56
On Thu, Apr 29, 2010 at 7:55 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > What happened, I don't find that story very compelling because there are an infinite number of ways to have high-availability not work if you start by supposing that the person who sets them up doesn't test them properly and verify that everything actually works as expected. You could do all sorts of things wrong in that case. 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. I think you can construct a scenario where just about any default setting causes a problem, but I like the idea of having this enabled by default, and I think it works fine if you just treat the case where recovery_connections=on but wal_mode=archive as a LOG or WARNING rather than an ERROR. ....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 |