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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-patches by date

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