Skip site navigation (1) Skip section navigation (2)

Re: fork/exec patch: pre-CreateProcess finalization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,"'Jan Wieck '" <JanWieck(at)Yahoo(dot)com>,"'''pgsql-patches(at)postgresql(dot)org' ' '" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Date: 2004-01-09 01:21:50
Message-ID: 18525.1073611310@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
> 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 <pgman(at)candle(dot)pha(dot)pa(dot)us> 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.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-01-09 01:23:40
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Bruce MomjianDate: 2004-01-09 01:16:04
Subject: Re: fork/exec patch: pre-CreateProcess finalization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group