Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Rob Wultsch on 6 May 2010 02:15 On Wed, May 5, 2010 at 9:32 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian <bruce(a)momjian.us> wrote: >> If someone wants to suggest that HS is useless if max_standby_delay >> supports only boolean values, I am ready to suggest we remove HS as well >> and head to 9.0 because that would suggest that HS itself is going to be >> useless. > > I think HS is going to be a lot less useful than many people think, at > least in 9.0. But I think ripping out max_standby_delay will make it > worse. > >> The code will not be thrown away; we will bring it back for 9.1. > > If that's the case, then taking it out makes no sense. > <mysql dba troll> I manage a bunch of different environments and I am pretty sure that in any of them if the db started seemingly randomly killing queries I would have application teams followed quickly by executives coming after me with torches and pitchforks. I can not imagine setting this value to anything other than a bool and most of the time that bool would be -1. I would only be unleashing a kill storm in utter desperation and I would probably need to explain myself in detail after. Utter desperation means I am sure I am going to have to do a impactful failover at any moment and need a slave completely up to date NOW. It is good to have the option to automatically cancel queries, but I think it is a mistake to assume many people will use it. What I would really need for instrumentation is the ability to determine *easily* how much a slave is lagging in clock time. </mysql dba troll> -- Rob Wultsch wultsch(a)gmail.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 6 May 2010 03:34 On Thu, 2010-05-06 at 00:47 -0400, Robert Haas wrote: > That just doesn't sound that bad to me, especially since the proposed > alternative is: > > - Queries will get cancelled like crazy, period. > > Or else: > > - Replication can fall infinitely far behind and you can write a > tedious and error-prone script to try to prevent it if you like. > > I think THAT is going to tarnish our reputation. Yes, that will. There is no consensus to remove max_standby_delay. It could be improved with minor adjustments and it makes more sense to allow a few of those, treating them as bugs. -- 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 6 May 2010 04:12 On Wed, 2010-05-05 at 23:15 -0700, Rob Wultsch wrote: > I manage a bunch of different environments and I am pretty sure that > in any of them if the db started seemingly randomly killing queries I > would have application teams followed quickly by executives coming > after me with torches and pitchforks. Fully understood and well argued, thanks for your input. HS doesn't randomly kill queries and there are documented work-arounds to control this behaviour. Removing the parameter won't help the situation at all, it will make the situation *worse* by removing control from where it's clearly needed and removing all hope of making the HS feature work in practice. There is no consensus to remove the parameter. -- 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 6 May 2010 05:26 Greg Smith <greg(a)2ndquadrant.com> writes: > If you need a script that involves changing a server setting to do > something, that translates into "you can't do that" for a typical DBA. The > idea of a program regularly changing a server configuration setting on a > production system is one you just can't sell. That makes this idea > incredibly more difficult to use in the field than any of the workarounds > that cope with the known max_standby_delay issues. I still think that the best API we can do in a timely fashion for 9.0 is: standby_conflict_winner = replay|queries pg_pause_recovery() / pg_resume_recovery() It seems to me those two functions are only exposing existing facilities in the code, so that's more an API change that a new feature inclusion. Of course I'm certainly wrong. But the code has already been written. I don't think we'll find any better to offer our users in the right time frame. Now I'll try to step back and stop repeating myself in the void :) 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 6 May 2010 05:36
On May 6, 2010, at 11:26 , Dimitri Fontaine wrote: > Greg Smith <greg(a)2ndquadrant.com> writes: >> If you need a script that involves changing a server setting to do >> something, that translates into "you can't do that" for a typical DBA. The >> idea of a program regularly changing a server configuration setting on a >> production system is one you just can't sell. That makes this idea >> incredibly more difficult to use in the field than any of the workarounds >> that cope with the known max_standby_delay issues. > > I still think that the best API we can do in a timely fashion for 9.0 > is: > > standby_conflict_winner = replay|queries > > pg_pause_recovery() / pg_resume_recovery() > > It seems to me those two functions are only exposing existing facilities > in the code, so that's more an API change that a new feature > inclusion. Of course I'm certainly wrong. But the code has already been > written. If there was an additional SQL-callable function that returned the backends the recovery process is currently waiting for, plus one that reported that last timestamp seen in the WAL, than all those different cancellation policies could be implemented as daemons that monitor recovery and kill backends as needed, no? That would allow people to experiment with different cancellation policies, and maybe shed some light on what the useful policies are in practice. best regards, Florian Pflug |