Re: Hot Standy introduced problem with query cancel behavior

On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
> On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >> Building racy infrastructure when it can be avoided with a little care
> >> still seems not to be the best path to me.
> >
> > Doing that will add more complexity in an area that is hard to test
> > effectively. I think the risk of introducing further bugs while trying
> > to fix this rare condition is high. Right now the conflict processing
> > needs more work and is often much less precise than this, so improving
> > this aspect of it would not be a priority. I've added it to the TODO
> > though. Thank you for your research.
> >
> > Patch implements recovery conflict signalling using SIGUSR1
> > multiplexing, then uses a SessionCancelPending mode similar to Joachim's
> > TransactionCancelPending.
>
> I have reworked Simon's patch a bit and attach the result.

Oh dear, this is exactly what I've been working on...

> Quick facts:
>
> - Hot Standby only uses SIGUSR1
> - SIGINT behaves as it did before: it only cancels running statements
> - pg_cancel_backend() continues to use SIGINT
> - I added pg_cancel_idle_transaction() to cancel an idle transaction via
> SIGUSR1
> - One central function HandleCancelAction() sets the flags before calling
> ProcessInterrupts(), it is called from the different signal handlers and
> receives parameters about what it should do
> - If a SIGUSR1 reason is used that will cancel something, ProcArrayLock is
> acquired until the signal has been sent to make sure that we won't signal the
> wrong backend. Does this sufficiently cover the concerns of Andres Freund
> discussed upthread?
>
> As there were so many boolean SomethingCancelPending variables I changed them
> to be bitmasks and merged all of them into a single variable. However I am not
> sure if we can change the name and type of especially InterruptPending that
> easily as it was marked with PGDLLIMPORT...
>
> @Simon: Is there a reason why you have not yet removed recoveryConflictMode
> from PGPROC?

--
Simon Riggs www.2ndQuadrant.com