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: 'Tom Lane ' <tgl(at)sss(dot)pgh(dot)pa(dot)us>,'Bruce Momjian ' <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,''''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 05:52:45
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B55F23F@harris.memetrics.local (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

Tom Lane wrote:
> I think the simplest way to make this work is to use an array that's 
> 2*MaxBackend items long (corresponding to the max number of children the
> postmaster will fork).  

Actually, now that I think about it, is even that big enough. There is a
reason BackendList is a list. In pathological situations, the postmaster
could be made to fork a much larger number than 2*MaxBackend simultaneous
children, although only this many will be allowed to become backends.
(I guess we could check the port->canAcceptConnections value, and not add
the backend to the array when == CAC_TOOMANY).

> There is no race condition possible for the ProcessCancelRequest case --- 
> the sub-postmaster that spawned an active backend must have found its 
> entry before it could have sent the cancel key to the client, so any 
> valid cancel request from a client must reference an already-existing 
> entry in the array.

Make sense. Great.

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 05:56:28
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Claudio NatoliDate: 2004-01-09 05:44:02
Subject: Re: fork/exec patch: pre-CreateProcess finalization

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