Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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
> > child before the signal handlers are installed. We don't have
> > this problem on unix because we fork and inherit the signal
> > handlers.
>
> FWIW, I think the todo's description of the problem is completely
> inaccurate. The issue is not the lack of signal handler settings per
OK, updated:
o Handle "lost signals" on backend startup (eg. shutdown,
config file changes, etc); signals are not possible on
startup
The problem here is that the postmaster might send signals to a
child before the Win32 pipe is created to accept signals.
We don't have this problem on unix because we fork and inherit
the signal handlers.
> 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?
> > The only solution I can think of for us is to set a PROC struct variable
> > when you can't send the Win32 backend a signal and have the backend
> > check this PROC variable after it starts listening for signals.
>
> A backend does not create its PROC entry until *long* after it gets
> forked, so this does not sound like a path to a solution. Also, I'd
> prefer to be able to signal non-backend children such as pgstat. (I'm
> not sure if the current code actually needs that, but I can definitely
> believe that we'll need to do it some day.) Also, we do need to be able
> to signal the postmaster from backends, so we cannot tie the signal
> mechanism to the assumption that every signalable process has or will
> eventually have a PROC entry.
OK.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
