> 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.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com