From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: fork() refactoring |
Date: | 2005-03-05 15:54:26 |
Message-ID: | 17388.1110038066@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-05 16:00:02 | Re: Display Pg buffer cache (WIP) |
Previous Message | Michael Fuhr | 2005-03-05 15:31:47 | Re: Exception ERROR Code |