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