Re: fork() refactoring

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

In response to

Responses

Browse pgsql-patches by date

  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