Re: [pgsql-hackers-win32] Win32 lost signals open item

Lists: pgsql-hackerspgsql-hackers-win32
From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "PostgreSQL Win32 port list" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [pgsql-hackers-win32] Win32 lost signals open item
Date: 2004-11-01 20:04:26
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE456A3E@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-hackers-win32

>> se, it is that our pipe-based emulation of signals isn't ready to
>> collect signal messages until some time after the child
>process starts.
>>
>> Could this be fixed by having the postmaster set up the pipe
>*before* it
>> forks/execs the child? We'd probably need to pass down some
>additional
>> info to inform the child where it has to hook into the pipe
>structure,
>> but passing down more state is no problem.
>
>Not sure. Magnus?

I think it can be made to work, but it's not as easy as one would hope.
Remember, the pipe is called \\.\pipe\pqsignal_<pid>, with the current
pid as a part of it.

The way to do it, I *think*, is to change the forkexec call to do (this
is all untested):
1) CreateProcess, with the flag CREATE_SUSPENDED. This creates all the
process structures, but specifically does not start the main thread.
This gives us the process id and handle.
2) Create the pipe with the correct name
3) Call DuplicateHandle() on the pipe to make it available in the
sub-process
4) Close the original pipe handle
5) Write the new handle to the backend parameter file somewhere
6) ResumeThread() on the new process, which actually starts the backend

As you can see, this is quite a bit more complicated than the simple
CreateProcess() call we have now.

It does, however, have a different advantage as well. The same kind of
thing will be required for a fix of the infamous "socket operation on
non socket because of LSP problems" we've been seeing quite a number of
reports on. The change being that instead of DuplicateHandle() we'd do
WSADuplicateSocket() for sockets to inherit.

If this seems like a reasonable approach, I can see if I can get
something together. But it's a fairly large change..

(Or if someone can poke a hole in the idea before I start, then please
do so..)

//Magnus


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "PostgreSQL Win32 port list" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [pgsql-hackers-win32] Win32 lost signals open item
Date: 2004-11-01 20:24:56
Message-ID: 24668.1099340696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-hackers-win32

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> [ proposed fix ]
> As you can see, this is quite a bit more complicated than the simple
> CreateProcess() call we have now.
> ...
> If this seems like a reasonable approach, I can see if I can get
> something together. But it's a fairly large change..

It sounds reasonable to me, in the sense that it is a localized change,
even if rather messy. (Perhaps this chunk of code should be pushed into
src/port someplace, instead of being dropped into postmaster.c?)

regards, tom lane