Re: fork/exec patch: pre-CreateProcess finalization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Claudio Natoli <claudio(dot)natoli(at)memetrics(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 02:33:52
Message-ID: 19743.1073615632@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> 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.

Actually, on further reflection a separate array to store PIDs and
cancel keys is probably a better idea. If we put this stuff in PGPROC
then the postmaster will need to be able to obtain the ProcStructLock
(or whatever it's called this week) in order to examine/modify that
data structure. That gets us into the usual concerns about backend bugs
locking up the postmaster, etc. But if it's a separate array then we
can just have the rule that no one but the postmaster gets to write in it.

I still think it's unnecessary to make a separate shmem segment for it,
though.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Jan Wieck 2004-01-09 02:46:54 Re: fork/exec patch: pre-CreateProcess finalization
Previous Message Jan Wieck 2004-01-09 01:37:56 Re: fork/exec patch: pre-CreateProcess finalization