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 and
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 - you
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 of
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
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 only 10%
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
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 part of the
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
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... ] OK, as
[ 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
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.
This gives a speed boost of about 10% on a program that calls
PQconnect/PQfinish in a tight loop on 10 parallell threads on my
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
12 matches
Mail list logo
