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
