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

Re: fork/exec patch: pre-CreateProcess finalization

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,"'Tom Lane '" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"''''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:46:54
Message-ID: 3FFE161E.3000200@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-patches
Bruce Momjian wrote:

> Claudio Natoli wrote:
>> 
>> Tom Lane writes:
>> > Actually, on further reflection a separate array to store PIDs and
>> cancel keys is probably a better idea.  
>> [snip]
>> > I still think it's unnecessary to make a separate shmem segment for it,
>> though.
>> 
>> Why is that? Don't we need the backends to have access to it to do a cancel
>> request? I think I've missed something here...
> 
> I think they are saying put the cancel key inside the existing shared
> memory segment.  I don't know when we actually attach to the main shared
> memory sigment in the child, but it would have to be sooner than when we
> need the cancel key.

I said move it into the PGPROC structure. And keep the pid in both, the 
PGPROC structure and postmaster local memory.

The backend attaches to the shared memory during 
AttachSharedMemoryAndSemaphores() ... where else?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #


In response to

pgsql-patches by date

Next:From: Claudio NatoliDate: 2004-01-09 02:48:25
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Tom LaneDate: 2004-01-09 02:33:52
Subject: Re: fork/exec patch: pre-CreateProcess finalization

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