
> >> 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

Thu, 29 Jul 2004 11:24:33 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: more signals (was: Function to kill backend)
"Magnus Hagander" <mha@sollentuna.net> writes:
> We invent something we could call "extended signals" that are valid only
> in pgsql.

This would be handy, but I dislike your proposal of implementing it
using SysV message queues.

1. Yes, the message facility should theoretically be there if shmem and
semaphores are there, but in the real world it might not be (Mac OS X
is an example of a platform that I don't think has all three SysV IPC
parts).

2. It's even more likely that it would be there but have unpleasantly
small implementation limits.  AFAICT your proposal requires a separate
message queue per backend, which is probably going to stress any
conventionally-configured SysV facility.

3. This doesn't seem to really address my objection of not being able to
trigger the signal manually.  Certainly kill(1) is not smart enough,
and even if we invent a pg_kill program, how will it know which message
queue to stick the extended signal in?  The IDs of the message queues
would not be readily available to anyone without access to the cluster's
shared memory, much less the mapping between message queue ID and
process PID.

			regards, tom lane

Thu, 29 Jul 2004 10:12:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more signals (was: Function to kill backend) 
Magnus Hagander wrote:
> 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.

I think we already have enough IPC uglyness without adding message
queues.  :-)

> 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?

At this point the big issue is terminating a backend session remotely. 
Let's get 7.5 out and see who else asks for it because right now I am
not even sure who wants it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 29 Jul 2004 12:14:18 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: more signals (was: Function to kill backend)