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

Thu, 29 Jul 2004 19:05:47 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: more signals (was: Function to kill backend) 