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

Re: fork/exec patch: pre-CreateProcess finalization

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Bruce Momjian ' <pgman(at)candle(dot)pha(dot)pa(dot)us>,Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: ''Tom Lane ' ' <tgl(at)sss(dot)pgh(dot)pa(dot)us>,''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 03:21:44
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F23C@harris.memetrics.local (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
> I think they are saying put the cancel key inside the existing shared
> memory segment.  

Ok. Thanks.

> 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.

Yes. Currently, it happens too late.

I'll put my hand up to have a go at this fixing this (and getting
processCancelRequest to work under Win32/EXEC_BACKEND at the same time), if
no one else particularly cares to.

Just to be clear, this would involve turning the BackendList dlllist into an
array in shared memory, right? If so, a couple of questions:
  - what is a suitably large size for this array (2 * MaxBackends, ala
  - the postmaster makes all calls referencing this list, with the exception
of processCancelRequest, correct? So, as Tom was alluding to, no locking is
required (or desired!), and we'll just need to be careful not to introduce a
race condition into processCancelRequest.

Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 


pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-01-09 04:46:27
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Bruce MomjianDate: 2004-01-09 02:52:42
Subject: Re: fork/exec patch: pre-CreateProcess finalization

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