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