Re: fork/exec patch: pre-CreateProcess finalization - Mailing list pgsql-patches

From Claudio Natoli
Subject Re: fork/exec patch: pre-CreateProcess finalization
Date
Msg-id A02DEC4D1073D611BAE8525405FCCE2B55F23F@harris.memetrics.local
Whole thread Raw
In response to fork/exec patch: pre-CreateProcess finalization  (Claudio Natoli <claudio.natoli@memetrics.com>)
Responses Re: fork/exec patch: pre-CreateProcess finalization  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.

Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

pgsql-patches by date:

Previous
From: Claudio Natoli
Date:
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Next
From: Bruce Momjian
Date:
Subject: Re: fork/exec patch: pre-CreateProcess finalization