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 по дате отправления:

Предыдущее
От: "Jeroen T. Vermeulen"
Дата:
Сообщение: Re: try/catch macros for Postgres backend
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Sketch of extending error handling for subtransactions in functions