From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Hot Standy introduced problem with query cancel behavior |
Date: | 2010-01-07 18:59:10 |
Message-ID: | 1262890750.19367.87918.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2010-01-07 at 19:23 +0100, Andres Freund wrote:
> On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
> >
> > As far as I can think at the moment, the best you can do is throw the
> > elog(ERROR), and if control gets out to the error recovery block in
> > PostgresMain, you can force a transaction abort there. In other words,
> > pretty much the same logic that was there before; the only addition that
> > I think is safe is to allow this to happen while DoingCommandRead, so
> > that you can cancel an idle transaction.
> Stupid question:
>
> Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything
> calling recv (especially in the EINTR) case?
> That way we can simply abort in the normal context without the constraint of
> an interrupt handler because recv() will finish after having serviced a signal
> handler.
>
> Sure there will be some parts calling CHECK_FOR_INTERRUPTS not often enough
> but thats surely not that critical - and after some time using a bit more
> force is ok I guess.
There's only a need for an immediate death when we were waiting for a
lock. In other cases a deferred death is possible. We could do that in
various places, such as each time we access a new data block.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-07 19:00:17 | Re: Streaming replication and postmaster signaling |
Previous Message | Bruce Momjian | 2010-01-07 18:53:41 | Re: Streaming replication and postmaster signaling |