>> I was also hoping to piggyback the socket fix on top of this
>> infrastructure. And that *requires* the
>write-files-after-createprocess
>> method. There is no other way.
>
>Oh, I had forgotten about that part of the problem. Okay, just gotta
>hold our noses and do it I guess.
>
>(Just to be c
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I was also hoping to piggyback the socket fix on top of this
> infrastructure. And that *requires* the write-files-after-createprocess
> method. There is no other way.
Oh, I had forgotten about that part of the problem. Okay, just gotta
hold our nos
>> 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 see
"Magnus Hagander" <[EMAIL PROTECTED]> 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_
>>> 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 reop
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> 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
>> Basically, I think internal_forkexec() needs to be split up
>into two -
>> one win32 and one other. For win32 version, it needs to
>CreateProcess()
>> *before* it does write_backend_variables(), and then pass
>the process id
>> as a parameter to write_backend_vars().
>
>Huh? Why?
Because we
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Basically, I think internal_forkexec() needs to be split up into two -
> one win32 and one other. For win32 version, it needs to CreateProcess()
> *before* it does write_backend_variables(), and then pass the process id
> as a parameter to write_backe
>> [ 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 s
"Magnus Hagander" <[EMAIL PROTECTED]> 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..
>> 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
>addit
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We have this open item:
> > Win32
> > o Handle "lost signals" on backend startup (eg. shutdown,
> > config file changes, etc); signals are SIG_DFL on startup
>
> > The problem here is that the postmast
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We have this open item:
> Win32
> o Handle "lost signals" on backend startup (eg. shutdown,
> config file changes, etc); signals are SIG_DFL on startup
> The problem here is that the postmaster might send signals to a
>
13 matches
Mail list logo
