Re: fork() refactoring

Tom Lane wrote:
> I'm worried about whether this doesn't break the EXEC_BACKEND case.
> Most of the code you've moved out isn't applicable to Windows, but
> the fflushes probably are

Right, which is why the patch adds fflushes to the Unix implementation
of internal_forkexec(). On reflection, it is probably more
straightforward to just invoke fork_process() from the Unix version of
internal_forkexec() -- attached is a revised patch that does this.

> Please do not apply without some further portability testing.

I've checked EXEC_BACKEND on Unix, and it seems to work. I don't have
access to a BeOS box, so I can't test that (and I wouldn't be surprised
if the port was pretty bitrotted already). Is there anything else you
want me to test before committing?

> I think it would be better to continue with your original thought of
> passing a token into this code so that the EXEC_BACKEND case could be
> handled too (the token would tell it which forkexec function to call).

The problem is that this was getting pretty complex; a lot of the
forkexec implementations want to pass data to the child process that is
private to the forkexec call site, for example. That means we still need
an #ifdef EXEC_BACKEND -- i.e. it's not such a win over the simpler
fork_process(). Since Magnus said he's thinking of refactoring this
anyway, I'm happy to leave it to him.

-Neil