> > This patch *replaces* the previous one. Contains the exact same
> > changes, except it *also* contains the move of the backend
> > file to shared memory on win32.
> Committed with some small editorializing. Possibly the
> weight of my concern about further dividing the Unix and
> Win32 cases can be brought home to you by pointing out that
> the non-Windows EXEC_BACKEND case had three different compile
> failures after applying the patch.
Really? I did test it on Linux before I sent it in.. Or rather, I
thought I did. Must have something badly broken in my EXEC_BACKEND setup
on Linux then - need to go check that.
What's the recommended way to compile in Unix with exec_backend? I've
just been editing headers/makefiles, and those get overwritetn at
configure - probably something like that happened in this case and I
didn't notice. There is no switch to configure from what I can see?
> I think the error recovery in the Windows internal_forkexec()
> routine is pretty shoddy --- most of the failure paths leak
> resources of one variety or another. Perhaps you can fix
> that during your upcoming code refactoring.
Yes. Some if it is leftover from before, and some is definitly new. But
most of these cases will either happen every time (= no backend startup
at all, so you'll notice real fast) or are "cannot happen" cases (like
can't close something). But yes, I'll try to get that into the
Just to make sure I'm following you completely - you are still saying
this refactoring waits until after 8.0, right? That's how I read it, but
I want to make sure you're not going to hold up anything further in in
the 8.0 beta waiting for something like this.
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2004-11-17 15:13:55|
|Subject: Re: Win32 signals & sockets |
|Previous:||From: Neil Conway||Date: 2004-11-17 08:29:47|
|Subject: Re: win32 cleanup|