> >> So what you'd basically need is a separate signal to trigger that > >> sort of exit, which would be easy ... if we had any spare > signal numbers. > > > What about multiplexing it onto an existing signal? e.g. set a > > shared-mem flag saying "exit after cancel" then send SIGINT? > > Possible, but then the *only* way to get the behavior is by > using the backend function --- you couldn't use dear old > kill(1) to do it manually. It'd be better if it mapped to a signal.
Okay, how is this for a proposed way of fixing this. Because as I see it, the problem is that there just aren't enough signals to go around. We invent something we could call "extended signals" that are valid only in pgsql. To do this, we steal one signal (durign the argument, let's say SIGUSR2 - can be another one, but that one seems like as good a choice as any). On top of this, we create a SystemV message queue used to pass down extended signals (should be supported on all systems that support sysv shared mem, and we require that..). We'd use the PID of the receiving backend as the message type, and pass the signal number as message contents. Now, in pqsignal() we change it into something along the line of: pqsignal() { if (signal > 256 || signal == SIGUSR2) { set_extended_signal_handler(); } else { set_normal_signal_handler(); } } and we create a sigusr2 handler like such: sigusr2handler() { while (read_signal_number_from_ipc()) { dispatch_extended_signal_handler(); } } and then we'd need to change the kill calls into being pqkill() { if (signal > 256 || signal==SIGUSR2) { send_signal_number_down_ipc_to_correct_backend(); native_kill(backend, SIGUSR2); } } I'm assuming that a normal signal number is never > 256. I'm not sure how safe that is, then we could just change the limit to something else (say 65536?) Doing it this way would mean that the actuall code using pqsignal() would never have to change - it wouldn't know if the signal was "normal" or "extended". And we could add thousands of signals if we ever wanted (ok, let's keep it real, but I'm assuming int he future we might want >1 at least). In this case, we would add XSIG_TERMONIDLE or something like that, which would tell the backend to exist as soon as it hits idle state. And the pg_term_backend() function could send a cancel-request followed by a termonindle-request to have the backnend abort the current statement/transaction and then exit. To the user it would be exposed using "pg_ctl kill" (that we already have). Which can of course also send normal signals. So we'd say "*never* use kill -<antyhing> on a pg backend, always use 'pg_kill kill', oh, and never -9 anything". This is more or less how it's done on win32 today (only there we do it for all signals - and this can and shuold definitly not be used to change the behaviour of things like SIGTERM that you'd normally see happen in a unix environment, that would just be dangerous). The current win32 implementatino could just be extended to send a int32 instead of a byte across the IPC channel already established. Does this sound like a reasonable way to extend the available signals? Or is it adding unnecessary stuff? And finally, if this sounds like a decent idea, is it too big to slip in as a bugfix for the term_backend() stuff into 7.5? //Magnus ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly