Re: [HACKERS] refactoring fork() and EXEC_BACKEND

2005-03-06 Thread Magnus Hagander
This is a lot like what I was planning to work towards with the refactoring of the forkexec code I promised to do for 8.1. Cool. BTW, have we accepted that EXEC_BACKEND is the way we're going to workaround the lack of fork() on Win32 for the foreseeable future? I mean, it _works_, but it's

Re: [HACKERS] refactoring fork() and EXEC_BACKEND

2005-03-05 Thread Neil Conway
Magnus Hagander wrote: This is a lot like what I was planning to work towards with the refactoring of the forkexec code I promised to do for 8.1. Cool. BTW, have we accepted that EXEC_BACKEND is the way we're going to workaround the lack of fork() on Win32 for the foreseeable future? I mean, it

Re: [HACKERS] refactoring fork() and EXEC_BACKEND

2005-03-04 Thread Magnus Hagander
While going through the usual motions needed to fork a child process of the postmaster, it occurred to me that there's a fair bit of duplicated code involved. There are also #ifdef for various situations (BeOS, LINUX_PROFILE, and EXEC_BACKEND), which makes the code yet more ugly. I think we

[HACKERS] refactoring fork() and EXEC_BACKEND

2005-03-03 Thread Neil Conway
While going through the usual motions needed to fork a child process of the postmaster, it occurred to me that there's a fair bit of duplicated code involved. There are also #ifdef for various situations (BeOS, LINUX_PROFILE, and EXEC_BACKEND), which makes the code yet more ugly. I think we