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

Re: refactoring fork() and EXEC_BACKEND

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Neil Conway" <neilc(at)samurai(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: refactoring fork() and EXEC_BACKEND
Date: 2005-03-06 18:44:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>> 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 don't beleive there is any other way than using threads. The only
"objects" you can create are processes and threads, and I don't know
there to be any other way to create a process than CreateProcess().

>> 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 
>> 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...

Win32 already passes it using shared memory. It was when I asked to get
that patch in during beta (or possibly even RC) that I promised to work
on the cleanup stuff for 8.1. For unix/exec_backend it still writes to a
file, but since that is never expected to be used in production where
performance is an issue...

I think that is a fairly clean way of doing it. You could pass it
through a pipe or something, but I don't see that it would be a cleaner
approach. You're still going to have a single place collecting all the
data, which is where most of the uglyness comes from.

>> 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 

Ok. I'll look at it once your stuff is done.


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-03-06 19:14:47
Subject: Speeding up tupledesc copying
Previous:From: Robert TreatDate: 2005-03-06 17:39:52
Subject: Re: Missing coalesce

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