Re: failover vs. read only queries
От | Robert Haas |
---|---|
Тема | Re: failover vs. read only queries |
Дата | |
Msg-id | AANLkTinjXj_9JT_HuRCEzAPYRZnxaM0ClHsXdchuzrV8@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: failover vs. read only queries (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Wed, Jun 9, 2010 at 3:22 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> To fix the problem, when the trigger file is found, I think >> that we should cancel all the running read only queries >> immediately (or forcibly use -1 as the max_standby_delay >> since that point) and make the recovery go ahead. If some >> people prefer queries over failover even when they create the >> trigger file, we can make the trigger behavior selectable in >> response to the content of the trigger file like pg_standby >> does. > > Well, the question is: are there users who would prefer not to have > slave queries cancelled and are willing to wait for failover? If so, > behavior of failover should really be slaved to max_standby_delay. If > not, there should be new behavior (i.e. "when the trigger file is found, > cancel all running queries"). One could argue that there are no users > of the first case. > > The fact that failover current does *not* terminate existing queries and > transactions was regarded as a feature by the audience, rather than a > bug, when I did demos of HS/SR. Of course, they might not have been > thinking of the delay for writes. > > If there were an easy way to make the trigger file cancel all running > queries, apply remaining logs and come up, then I'd vote for that for > 9.0. I think it's the more desired behavior by most users. However, > I'm opposed to any complex solutions which might delay 9.0 release. One complication here is that, at least as I understand it, Tom is planning to overhaul max_standby_delay. So it might be premature to try to figure out how this should work until the dust settles. But my intuition is similar to yours, overall. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: