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: 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 (view raw or flat)
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

pgsql-patches by date

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

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