"Magnus Hagander" <[EMAIL PROTECTED]> writes: > 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). 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. 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? 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. regards, tom lane ---------------------------(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