On Thu, 2009-12-31 at 13:14 +0100, Andres Freund wrote:
> > > When cancelling a backend that behaviour could be a bit
> annoying ;-)
> >
> > Reading comments alone doesn't show the full situation here.
> >
> > Before we send signal we check pid also, so the chances of this
> > happening are fairly small. i.e. we would need to have a backend
> slot
> > reused by a new backend with exactly same pid as the last slot
> holder.
> Well. The problem does not occur for critical errors (i.e. session
> death)
> only. As signal delivery is asynchronous it can very well happen for
> transaction cancellation as well.
> > I'm proposing to use this for killing transactions and connections,
> so I
> > don't think there's too much harm done there. If the backend is
> leaving
> > anyway, that's what we wanted. If its a new guy that is wearing the
> same
> > boots then a little collateral damage doesn't leave the server in a
> bad
> > place. HS cancellations aren't yet so precise that this matters.
> 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.
I enclose the patch I am currently testing, as a patch-on-patch on top
of Joachim's changes, recently published on this thread. POC only as
yet.
Patch implements recovery conflict signalling using SIGUSR1
multiplexing, then uses a SessionCancelPending mode similar to Joachim's
TransactionCancelPending.
--
Simon Riggs www.2ndQuadrant.com