Re: more signals (was: Function to kill backend) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: more signals (was: Function to kill backend)
Date
Msg-id 13752.1091110342@sss.pgh.pa.us
Whole thread Raw
In response to Re: more signals (was: Function to kill backend)  ("Magnus Hagander" <mha@sollentuna.net>)
List 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 by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: try/catch macros for Postgres backend
Next
From: Peter Eisentraut
Date:
Subject: Re: Sketch of extending error handling for subtransactions in functions