Re: Cancelling idle in transaction state

On Fri, 2010-01-01 at 17:14 +0200, Heikki Linnakangas wrote:

> > Which amounts to rejecting this patch, since *this* patch changes the
> > behaviour of SIGINT for all senders, which is what I understood people
> > desired, i.e. not just a change for Hot Standby. I assumed Joachim did
> > not mean to veto his own patch, but I'm not sure what you think here?
> > (I don't mind either way).
>
> I don't know, I don't feel strongly about this. Is there really no other
> way?

Multiple behaviours on signal implies multiplexing, AFAICS.

Question on the table is: Should SIGINT be extended to cancel an
idle-in-transaction session, or not? I'll wait a little while longer
before committing this to make sure I have the full spread of opinion.

Tom's opinion was...

On Tue, 2009-12-29 at 10:22 -0500, Tom Lane wrote:
> Joachim Wieland <joe(at)mcknight(dot)de> writes:
> > If we use the same signal for both cases, the receiving backend cannot
> > tell what the intention of the sending backend was. That's why I
> > proposed to make SIGINT similar to SIGUSR1 where we write a reason to
> > a shared memory structure first and then send the signal (see
> > http://archives.postgresql.org/pgsql-hackers/2009-12/msg02067.php from
> > a few days ago).
>
> This seems like a fairly bad idea. One of the intended use-cases is to
> be able to manually "kill -INT" a misbehaving backend. Assuming that
> there will be valid info about the signal in shared memory will break
> that.

So it seems that we have at least one vote in favour of making SIGINT
blow anything away, no matter what its state.

I support that also, but I don't need it for HS, its just an objective
opinion. So that's plus 2, unsure about Joachim. Any others?

> Seems useful to me, so that you know why your transaction was cancelled.
> It's rather weird to see no ERRORs in the previous steps, and suddenly
> you see that the transaction is aborted. And none your savepoints exist
> anymore either.

I agree we need a message to explain, it just seems wrong to me to do
this in a way that appears to accentuate this particular source of error
over similar sources.

However, I will do as requested, though will leave existing error
sources alone.

--
Simon Riggs www.2ndQuadrant.com