Claudio Natoli <claudio.natoli@memetrics.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
necessary.
regards, tom lane