Thread: Re: 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

"Magnus Hagander" <mha@sollentuna.net> 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

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