"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
