Re: Win32 signals & sockets

>> 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% on something
>that isn't a performance issue for properly written
>applications anyway.
>
>Can I safely ignore this patch and use the prior one, or are there
>additional bug fixes in this?

You can, there are no additional bug fixes.

But let me give it a shot to try to convince you to put it in there
anyway :-)

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 patch. It's basically two API calls int he postmaster
(parent) and one in the backend.

Considering that this is very little code, uses only very core features
on the win32 API, and will be exercised *all the time* (every backend
startup, ever), we should see errors in thise codepath pretty soon. If
we do, we can always back it out before RC instead of trying to fix it.

Just the speedup is not the only reason to apply it. Continually
creating and deleting a file in the directory will also cause the
filesystem journal and MFT entries to build up significantly. (Every
file commit also requires a flush of the filesystem journal, which I
beleive is where those 10% are found. The difference would probably be
greater than 10% on a system that is I/O loaded, but I haven't tested
that)

(The reason the patch looks pretty much different from the first patch
is that a couple of structures had to be moved higher up in postmaster.c
causing the diff to be larger)

But the summary still holds - this is not a *critical* bug fix. I'd
argue it's a bug fix, but we *can* do without it.

//Magnus

(No, I'm not going to push for the next stage of forkexec cleanups to go
in 8.0 :P)