Skip site navigation (1) Skip section navigation (2)

Re: refactoring fork() and EXEC_BACKEND

From: Neil Conway <neilc(at)samurai(dot)com>
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: refactoring fork() and EXEC_BACKEND
Date: 2005-03-05 08:59:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 _works_, but it's slow, ugly, and complicates the code. If it's 
the only workable option for Win32 support, then fair enough -- I just 
don't know enough of the Win32 API to know if there's a better 
alternative out there (short of using threads, which is of course not 
really plausible).

> I was actually thinking of not passing these on the commandline at all,
> in order to avoid possible quoting issues etc (recall all the problems
> with the stupid commandline processing on win32). Instead moving it into
> a struct that is appended to the end of the backend variable file/shared
> memory.

Sounds good to me. Finding a cleaner way to pass data to the child 
process than writing it out to a file would also be nice, if possible. 
Again, I'm not sure what options there are on Win32...

> That was also what I was thinking. Let me know if you want to split the
> load somewhere :-)

Given that you're planning to work on this, I've scaled back my 
ambitions. I'll send a patch to -patches that just cleans up fork() and 
doesn't change the EXEC_BACKEND case. So fork_process() will:

- flush stderr/stdout
- save and restore the profiling timer if LINUX_PROFILE is defined
- handle BeOS

which means it should not be very invasive. Of course, there is plenty 
of room for improvement -- if you're interested in taking a look, please 


In response to

pgsql-hackers by date

Next:From: Ali BabaDate: 2005-03-05 14:03:20
Subject: Exception ERROR Code
Previous:From: Pailloncy Jean-GerardDate: 2005-03-05 08:59:14
Subject: Re: bitmap AM design

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group