> > What's the recommended way to compile in Unix with exec_backend?
>
> I don't think we have a recommended way (or need one really).
> Personally I add #define EXEC_BACKEND to pg_config.h after
> configuring.
Right. That's what I've been doing. Just need to be more careful
checking the result
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> What's the recommended way to compile in Unix with exec_backend?
I don't think we have a recommended way (or need one really).
Personally I add #define EXEC_BACKEND to pg_config.h after configuring.
> Just to make sure I'm following you completely -
> > This patch *replaces* the previous one. Contains the exact same
> > changes, except it *also* contains the move of the backend
> parameter
> > file to shared memory on win32.
>
> Committed with some small editorializing. Possibly the
> weight of my concern about further dividing the Unix
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch *replaces* the previous one. Contains the exact same changes,
> except it *also* contains the move of the backend parameter file to
> shared memory on win32.
Committed with some small editorializing. Possibly the weight of my
concern abou
[ grumble... ] OK, as long as Magnus is promising a code-beautification
patch. postmaster.c is rapidly approaching a condition of unreadability
== unmaintainability == perl ;).
regards, tom lane
---(end of broadcast)---
TIP
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I've been following this thread for a bit and I have to admit I wouldn't
> mind seeing the shmmem part of Magnus's patch go in. Windows suffers vs
> unix generally on process creation times and any improvement here would
> be welcome.
[ grumble... ]
Tom Lane wrote:
> It's the increase in variance between the Unix and Windows code paths
> that's really bothering me. We went into this project on the promise
> that there weren't going to be thousands of lines of #ifdef WIN32
stuff,
> and I'm not happy in the least with the way postmaster.c looks
>> I realise it's late in the beta. But all the actually
>*complicated* code
>> in this patch is in the first patch - the splitting up of the
>> CreateProcess/ResumeThread steps and the WSADuplicateSocket code. The
>> part that moves the param file -> shared memory is a very small and
>> simple pa
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> I think it's way too late in the beta cycle for significant changes in
>> the fork mechanism ...
> I realise it's late in the beta. But all the actually *complicated* code
> in this patch is in the first patch - the splitting up of the
> CreateProce
>> This patch *replaces* the previous one. Contains the exact
>same changes,
>> except it *also* contains the move of the backend parameter file to
>> shared memory on win32.
>
>I think it's way too late in the beta cycle for significant changes in
>the fork mechanism ... especially if the gain is
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch *replaces* the previous one. Contains the exact same changes,
> except it *also* contains the move of the backend parameter file to
> shared memory on win32.
I think it's way too late in the beta cycle for significant changes in
the fork m
22:21
>To: PostgreSQL Patches
>Subject: [PATCHES] Win32 signals & sockets
>
>
>Finally, here is the patch:
>
>* Create the signal pipe in the postmaster and then inherit it into the
>child
>* Duplicate sockets using WSADuplicateSocket/WSASocket to get around
>buggy LSP imp
Magnus Hagander wrote:
If this is accepted I also plan to do a patch to split out the forkexec
code into a separate file and try to clean up the dependencies a bit
further. It'd be nice if I could get that into 8.0.0 (which would
probably mean this beta, since it seems to be the last one), but it'
Finally, here is the patch:
* Create the signal pipe in the postmaster and then inherit it into the
child
* Duplicate sockets using WSADuplicateSocket/WSASocket to get around
buggy LSP implementations. From my testing this does not solve *all*
problems, but it does solve a lot of them.
* Change pg
14 matches
Mail list logo
