Re: failover vs. read only queries - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: failover vs. read only queries
Date
Msg-id 1276123363.23257.1053.camel@ebony
Whole thread Raw
In response to Re: failover vs. read only queries  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Wed, 2010-06-09 at 12:22 -0700, Josh Berkus 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.

+1

Just to add: there is only a delay in triggering *if* the standby is
waiting on a query at or after triggering. If there is a wait, it is
never more than max_standby_delay, which is what the user said they
would be happy to accept.

> 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.

In 8.4 you could specify "fast" failover or "smart" failover. In 9.0,
AFAICS we have only implemented "smart" failover, which means it will
continue until the end of the WAL stream before triggering. So under
heavy streaming load or with considerable lag the trigger won't cause
failover for some time. So there is less function in 9.0 than was
available in 8.4. If that removal was intended, it wasn't discussed.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Next
From: Josh Berkus
Date:
Subject: Bug or feature? Timestamp parsing