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