Re: fork() refactoring - Mailing list pgsql-patches

From Tom Lane
Subject Re: fork() refactoring
Date
Msg-id 17388.1110038066@sss.pgh.pa.us
Whole thread Raw
In response to fork() refactoring  (Neil Conway <neilc@samurai.com>)
Responses Re: fork() refactoring  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> This patch moves all the common code that is usually invoked before
> doing a fork() into a single function, fork_process(). It is not aware
> of the EXEC_BACKEND machinery, so it should be used as fork() currently
> is -- inside an #ifndef EXEC_BACKEND block, if appropriate.

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 --- and they are certainly applicable when
testing EXEC_BACKEND mode on a Unix machine, which is a case you may
*not* break because it will render Windows completely unsupportable.

> Barring any objections, I'll apply this to HEAD on Monday.

Please do not apply without some further portability testing.

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).
That would probably mean that the function has to stay within
postmaster.c, but as long as it consolidates the N cases of fork
decoration into one, we're still ahead of the game.

            regards, tom lane

pgsql-patches by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Display Pg buffer cache (WIP)
Next
From: Tom Lane
Date:
Subject: Re: Display Pg buffer cache (WIP)