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

Re: fork/exec patch: pre-CreateProcess finalization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "'pgsql-patches(at)postgresql(dot)org'" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Date: 2003-12-26 16:48:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> This has required some reworking of the existing code base, particularly to
> BackendFork (which now actually does the fork()). As such, I've been
> anticipating that this will be the most controversial of the fork/exec
> patches, so critique away :-)

You haven't explained why that's necessary.  Given the fact that this
patch seems to hugely complicate the postmaster logic --- not so much
either path individually, but the messy #ifdef interleaving of two
radically different programs --- I am inclined to reject it on style
grounds alone.

We should either find a way to make the fork/exec path more like the
existing code, or bite the bullet and change them both.  Doing it the
way you have here will create an unmaintainable mess.  I'm not prepared
to work on a postmaster in which a step as basic as fork() happens in
two different places depending on an #ifdef.

If you want to change them both, let's first see the reason why it's

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2003-12-26 17:09:11
Subject: Re: fork/exec patch: pre-CreateProcess finalization
Previous:From: Claudio NatoliDate: 2003-12-26 07:11:49
Subject: fork/exec patch: pre-CreateProcess finalization

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