Re: [HACKERS] more signals (was: Function to kill backend)
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
Re: [HACKERS] more signals (was: Function to kill backend)
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] more signals (was: Function to kill backend)
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). Ok. Yikes. Any suggestions for alternative methods= 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. Not at all. One message queue with the backend pid as the message id. Eh. One message queue per cluster, that is. 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? We have already invented pg_kill. It's pg_ctl kill. 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. ftok() on pg_control or something in the clusters data directory was my intention. (Again, just one message queue) //Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] more signals (was: Function to kill backend)
Magnus Hagander [EMAIL PROTECTED] writes: 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. Not at all. One message queue with the backend pid as the message id. Oh, I had forgotten about the message type notion. Okay, you could use that to multiplex by PID. But the problem of small implementation limits remains. For instance it might fail to send a message to every backend :-( 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. ftok() on pg_control or something in the clusters data directory was my intention. (Again, just one message queue) Doesn't work; you have to be able to cope with collisions with previously existing queue IDs ... so in practice the queue ID has to be treated as quasi-random. See the semaphore ID selection logic we use now. I tend to agree with Bruce's nearby comment that we shouldn't be trying to solve this now. I'd vote for commenting out the session-kill function for 7.5, and revisiting the issue sometime in future. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] more signals (was: Function to kill backend)
Tom Lane wrote: ftok() on pg_control or something in the clusters data directory was my intention. (Again, just one message queue) Doesn't work; you have to be able to cope with collisions with previously existing queue IDs ... so in practice the queue ID has to be treated as quasi-random. See the semaphore ID selection logic we use now. I tend to agree with Bruce's nearby comment that we shouldn't be trying to solve this now. I'd vote for commenting out the session-kill function for 7.5, and revisiting the issue sometime in future. I already have it on the TODO list. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] more signals (was: Function to kill backend)
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. Not at all. One message queue with the backend pid as the message id. Oh, I had forgotten about the message type notion. Okay, you could use that to multiplex by PID. But the problem of small implementation limits remains. For instance it might fail to send a message to every backend :-( Hmm. Right. 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. ftok() on pg_control or something in the clusters data directory was my intention. (Again, just one message queue) Doesn't work; you have to be able to cope with collisions with previously existing queue IDs ... so in practice the queue ID has to be treated as quasi-random. See the semaphore ID selection logic we use now. Hmm. Ok. Good point. I tend to agree with Bruce's nearby comment that we shouldn't be trying to solve this now. I'd vote for commenting out the session-kill function for 7.5, and revisiting the issue sometime in future. Ok. Go for that. Might there be point to adding the implement a way to increase number of usable signals as a separate TODO item? //Magnus ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
