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