max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Robert Haas on 9 May 2010 12:52 On Sun, May 9, 2010 at 12:47 PM, Greg Stark <gsstark(a)mit.edu> wrote: > On Sun, May 9, 2010 at 4:00 AM, Greg Smith <greg(a)2ndquadrant.com> wrote: >> The use cases are covered as best they can be without better support from >> expected future SR features like heartbeats and XID loopback. > > For what it's worth I think deferring these extra complications is a > very useful exercise. I would like to see a system that doesn't depend > on them for basic functionality. In particular I would like to see a > system that can be useful using purely WAL log shipping without > streaming replication at all. > > I'm a bit unclear how the boolean proposal would solve things though. > Surely if you set the boolean to recovery-wins then when using > streaming replication with any non-idle master virtually every query > would be cancelled immediately as every HOT cleanup would cause a > snapshot conflict with even short-lived queires in the slave. It sounds to me like what we need here is some testing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 9 May 2010 14:52 On Sat, 2010-05-08 at 20:57 -0400, Tom Lane wrote: > Andres Freund <andres(a)anarazel.de> writes: > > On Sunday 09 May 2010 01:34:18 Bruce Momjian wrote: > >> I think everyone agrees the current code is unusable, per Heikki's > >> comment about a WAL file arriving after a period of no WAL activity, and > >> look how long it took our group to even understand why that fails so > >> badly. > > > To be honest its not *that* hard to simply make sure generating wal regularly > > to combat that. While it surely aint a nice workaround its not much of a > > problem either. > > Well, that's dumping a kluge onto users; but really that isn't the > point. What we have here is a badly designed and badly implemented > feature, and we need to not ship it like this so as to not > institutionalize a bad design. No, you have it backwards. HS was designed to work with SR. SR unfortunately did not deliver any form of monitoring, and in doing so the keepalive that it was known HS needed was left out, although it had been on the todo list for some time. Luckily Greg and I argued to have some monitoring added and my code was used to provide barest minimum monitoring for SR, yet not enough to help HS. Of course, if one team doesn't deliver for whatever reason then others must take up the slack, if they can: no complaints. Since I personally didn't know this was going to be the case until after freeze, it is very late to resolve this situation sensibly and time has been against us. It's much harder for me to reach into the depths of another person's work and see how to add necessary mechanisms, especially when I'm working elsewhere. Even if I had done, it's likely that I would have been blocked with the "great idea, next release" response as already used on this thread. Without doubt the current mechanism suffers from the issues you mention, though the current state is not the result of bad design, merely inaction and lack of integration. We could resolve the current state in many ways, if we chose. Bruce has used the word crippleware for the current state. Raising a problem and then blocking solutions is the best way I know to cripple a release. It should be clear that I've done my best to avoid this situation and have been active on both SR and HS. Had I not acted as I have done to date, SR would at this point slurp CPU like a bandit and be unmonitorable, both fatal flaws in production. I point this out not to argue, but to set the record straight. IMHO your assignment of blame is misplaced and your comments about poor design do not reflect how we arrived at the current state. -- 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 9 May 2010 15:04 On Sun, 2010-05-09 at 16:10 +0200, Florian Pflug wrote: > Adding pause/resume seems to introduce some non-trivial locking > problems, though. How would you handle a pause request if the recovery > process currently held a lock? (We are only talking about AccessExclusiveLocks here. No LWlocks are held across WAL records during replay) Just pause. There are no technical problem there. Perhaps a danger of unforeseen consequences, though doing that might also be desirable, who can say? -- 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: Dimitri Fontaine on 9 May 2010 15:09 Florian Pflug <fgp(a)phlo.org> writes: > The only remaining option is to continue applying WAL until you reach > a point where no locks are held, then pause. But from a user's POV > that is nearly indistinguishable from simply setting > hot_standby_conflict_winner to in the first place I think. Not really, the use case would be using the slave as a reporting server, you know you have say 4 hours of reporting queries during which you will pause the recovery. So it's ok for the pause command to take time. What I understand the boolean option would do is to force the user into choosing either high-availability or using the slave for other purposes too. The problem is in wanting both, and that's what HS was meant to solve. Having pause/resume allows for a mixed case usage which is simple to drive and understand, yet fails to provide adaptive behavior where queries are allowed to pause recovery implicitly for a while. In my mind, that would be a compromise we could reach for 9.0, but it seems introducing those admin functions now is to far a stretch. I've been failing to understand exactly why, only getting a generic answer I find unsatisfying here, because all the alternative paths being proposed, apart from "improve documentation", are more involved code wise. Regards, -- dim -- 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: Florian Pflug on 9 May 2010 15:50
On May 9, 2010, at 21:04 , Simon Riggs wrote: > On Sun, 2010-05-09 at 16:10 +0200, Florian Pflug wrote: > >> Adding pause/resume seems to introduce some non-trivial locking >> problems, though. How would you handle a pause request if the recovery >> process currently held a lock? > > (We are only talking about AccessExclusiveLocks here. No LWlocks are > held across WAL records during replay) > > Just pause. There are no technical problem there. > > Perhaps a danger of unforeseen consequences, though doing that might > also be desirable, who can say? No technical problems perhaps, but some usability ones, no? I assume people would pause recovery to prevent it from interfering with long-running reporting queries. Now, if those queries might block indefinitely if the pause request by chance was issued while the recovery process held an AccessExclusiveLock, then the pause *caused* exactly what it was supposed to prevent. Setting hot_standby_conflict_winner to "queries" would at least have allowed the reporting queries to finish eventually. If AccessExclusiveLocks are taken out of the picture (they're supposed to be pretty rare on a production system anyway), setting hot_standby_conflict_winner to "queries" seems to act like a conditional pause request - recovery is paused as soon as it gets in the way. In this setting, the real advantage of pause would be to prevent recovery from using up all available IO bandwidth. This seems like a valid concern, but calls more for something like recovery_delay (similar to vacuum_delay) instead of pause(). best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |