Re: more signals (was: Function to kill backend)
От | Tom Lane |
---|---|
Тема | Re: more signals (was: Function to kill backend) |
Дата | |
Msg-id | 13752.1091110342@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: more signals (was: Function to kill backend) ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-hackers |
"Magnus Hagander" <mha@sollentuna.net> 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
В списке pgsql-hackers по дате отправления: