| Lists: | pgsql-hackerspgsql-hackers-win32 |
|---|
| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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 21:02:21 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE47607A@algol.sollentuna.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-hackers-win32 |
>>> Huh? Why?
>
>> Because we need to write the duplicated socket
>structure/pipe handle to
>> the parameter file. I guess we could create a separate parameter file
>> just for these things, but that seemed a bit unnecessary.
>
>Do we actually need to pass the handle, or could the subprocess reopen
>the pipe for itself?
Nope, we need to pass the handle. Only one process can be the
server-side of the pipe, and once the postmaster has opened it, the
child process can't do it - the only way to get it is through
inheritance.
//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 21:11:10 |
| Message-ID: | 25350.1099343470@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:
> Nope, we need to pass the handle. Only one process can be the
> server-side of the pipe, and once the postmaster has opened it, the
> child process can't do it - the only way to get it is through
> inheritance.
Grumble. Having to call write_backend_variables from two different
places seems Really Ugly.
How about Plan B? It occurs to me that what this proposal really does
is to delay the postmaster until after the child process has been
created. What about doing that in some more straightforward fashion
--- that is, the postmaster doesn't return from win32_forkexec until
it sees that the child has gotten at least as far as being able to
accept signals? (A simple way to do it would just be to loop trying to
kill(0) the child PID.) I guess the tricky part here is recovering if
the child fails to start at all --- a timeout would perhaps do but it's
ugly. Still, seems less ugly than the way this idea is panning out.
regards, tom lane