pgsql: MakeCheckRequiredParameterValues() depend upon correct
in [PgSql]
|
Prev: pgsql: Make CheckRequiredParameterValues()depend upon correct
Next: [HACKERS] Schema.Table.Col resolution seems broken in Alpha5
From: Simon Riggs on 29 Apr 2010 06:19 On Thu, 2010-04-29 at 12:55 +0300, Heikki Linnakangas wrote: > Seems overly complicated. If you turn wal_level = hot_standby in the master, then the slaves work, unless you say otherwise. What is complicated about that? > It would be simpler to just set it 'off' by > default. As a parameter, yes, it is simpler. The behaviour is not simplified by doing that. I care about the behaviour. > If it's 'off' by default, and you want to use hot standby, you will > notice quickly that the server doesn't accept connections, and you > switch it on. If it's 'on' (or 'auto'), you might not realize that your > standby server is accepting connections, when you only wanted to set it > up as a warm standby server for high availability. That requires we hit the problem, alter the parameter and restart. We don't need to do that at all. It could "Just Work". > The 'auto' mode just makes it more surprising. Connections might be > allowed at first, but when someone switches wal_level in the primary for > some reason, your reporting standby is up, but no longer allows > connections. If you don't do this, what would happen on standby? Does it silently stop applying changes after the point you turned it off, or does it throw an ERROR. > And vice versa, if you set up a warm standby server for > high availability where you don't want to allow connections, and someone > flips the wal_level switch in the master, the standby suddenly starts > accepting connections. Some people would regard that as a good thing. The whole point of wal_level discussion was to avoid needing multiple switches to turn something on. You are proposing exactly that here. Why is this discussion different? Why should we not be able to set in just one place. If that behaviour concerns the DBA then they can turn it off explicitly. > I can't imagine a situation where "allow connections if the WAL allows > it" would be a sensible setting. If there is one, we could have an > 'auto' mode, but not as the default. I can. Simple, obvious behaviour. Turn it on in the master, works on the standbys. We want people to use the feature, not fumble with it. Just think "auto" means "linked to master". If you don't like it you can turn it off. -- Simon Riggs www.2ndQuadrant.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: Simon Riggs on 29 Apr 2010 07:17 On Thu, 2010-04-29 at 13:46 +0300, Heikki Linnakangas wrote: > purpose of the standby - do you want hot standby or not? > reporting - yes > offloading queries from master - yes > offloading pg_dump from master - yes These would work using the proposed default. > warm standby for high availability - no > offloading taking filesystem-level backups from master - no These can be explicitly turned off. You're presuming there is benefit in turning recovery_connections = off, though it is perfectly valid to do those use cases with it on. There are many ways to control connections, not just that switch. It will certainly be easier to monitor the HA system by running queries against it than not. Do you have any evidence there is benefit in the *typical* case for turning the setting off? > All of those either want hot standby, or don't. What use case is there > for "enabled, if the required information is in the WAL"? If there is > one, it sure doesn't seem like the most common one. I think "I want it to just work" is fairly common. > When you just want > hot standby to be on or off, it's weird to control that from the master. > Action at a distance. That's the proposed default, not the only control. The standby can override what the master says if it definitely doesn't want it, but is smart enough to avoid silly configuration errors. Turning off wal_level on the master *does* affect the standby, so pretending we have a completely separate configuration option makes no sense for me. Robert's point when he raised the wal_level discussion was about reducing the number of parameter settings required to make this work. An intelligent default will reduce level of configuration and allow us to make Hot Standby work on the standby, out of the box, and that is worth having. -- Simon Riggs www.2ndQuadrant.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: Simon Riggs on 29 Apr 2010 08:19 On Thu, 2010-04-29 at 14:55 +0300, Heikki Linnakangas wrote: > I'd like to scaremonger Seems so. recovery_connections was on by default and unanimous agreement until recently and I don't want to change that now, just because a change somewhere else appears to be forcing that but need not be so. It was sensible to add a switch to turn HS off, but it should not be the default, especially not one that requires a restart to enable a high availability feature. That is important in a feature that takes a while to "kick-in" and so the user may patiently wait for it to come up and it never does. I have no wish to repeat the situation that PostgreSQL requires a restart to enable a feature, while other forks retain the ability to enable the parameter without restart, as occurs with archive_mode, IIRC. Perhaps we should not re-think wal_level if we've just moved the parameter problem somewhere else? -- Simon Riggs www.2ndQuadrant.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: Simon Riggs on 29 Apr 2010 11:24 On Thu, 2010-04-29 at 09:48 -0400, Tom Lane wrote: > 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. We're talking about the case where somebody has set up a standby database. It's not like they happen on this accidentally. * HS on by default, in the standby, via recovery_connections. * HS off by default, in the master, via wal_level. Overall, that *is* off by default. (Note: I said nothing about that). We don't need it off *twice*, nor do we even need two switches. Last week we had one switch and it was on by default, now we're looking at two switches and off by default. I haven't yet heard a good reason for the change being proposed here by Heikki. The use cases are rare, if they truly exist at all. Monitoring the standby is much easier with HS on, for example. What is the reason for the *extra* "off" switch? Why two? Why "off" twice? -- Simon Riggs www.2ndQuadrant.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: Aidan Van Dyk on 29 Apr 2010 11:37
* Simon Riggs <simon(a)2ndQuadrant.com> [100429 11:24]: > > What is the reason for the *extra* "off" switch? Why two? Why "off" > twice? Because I run a PITR slave off a WAL archive... And I'm going to continue to try and use this setup... I expect to try and experiment with wal-streaming too when everything is up to 9, and be a little upset when the "old faithfull" backup I've got and am betting my job on suddenly starts acting differentlyl, or accepting connections and causing my db clients to start thowing errors because I'm trying to get a streaming replication w/ hot standby up on a *different* slave... 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. There has got to be *something* that tells me it is trying to allow connectins during recovery, but failing... And i think that just loging a WARNING and continuing isn't enough, because I'll admit to having upgraded PG and just "testing" it, not looking thoroughly through the logs for any new messages that might peak my interest... That said, since I follow -hackers, that "something" could be considered this email thread, and I know I will be extra careful about my deployment of PITR slaves w/ 9 wrt making sure I'm explicit in all the settings I can find... And I'll make sure I look more carefully at logs when deploying 9 as well ;-) a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave. |