Re: max_standby_delay considered harmful
От | Rob Wultsch |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | h2i2c5ef4e31005052315ga27b6ba0l758d2ee8692ce452@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: max_standby_delay considered harmful
Re: max_standby_delay considered harmful |
Список | pgsql-hackers |
On Wed, May 5, 2010 at 9:32 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian <bruce@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@gmail.com
В списке pgsql-hackers по дате отправления: