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
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.
> 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.
regards, tom lane