Tom Lane wrote:> Claudio Natoli wrote: >> The only things I've thought of so far are: >> a) sticking the PID/cancel key list in shared mem [yeech] >> b) rearranging the entire cancel handling to occur in the postmaster [double >> yeech]
(a) seems like the lesser of the available evils (unless someone has a bright idea for a plan C).
Bruce Momjian <[EMAIL PROTECTED]> writes: > I think we need to move in the direction of a separate fork/exec-only > shared memory segment that holds the pids and cancel keys for all the > backends.
That doesn't seem worth the trouble. I'd be inclined to just stick the cancel keys in the PGPROC structures (I believe the PIDs are already in there). The original motivation for keeping them only in postmaster local memory was to keep backend A's cancel key away from the prying eyes of backend B, but is there really any security added? Anyone who can inspect PGPROC hardly needs to know the cancel key --- he can just issue a SIGINT (or worse) directly to the target backend.
Agreed. I was going for a separate one just to be paranoid. This will only be done for exec(), so I don't see a problem for normal Unix use anyway.
It doesn't hurt to keep the locations and code as much in sync as possible. I think Tom's idea to move the information into the PGPROC entry is the winner and does not need any OS specific handling.
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]