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 <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
