Win32 lost signals open item

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.

Win32 uses a special socket to receive signals and does not use the
standard Unix signal mechanism. However, the socket doesn't exist on
backend process start so there is possible loss of signal while the
backend starts.

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.
However, there would still be a window where the signal could fail but
the backend could check the variable before the postmaster sets it so we
might just set the variable before a signal is sent and because it is
only checked when we start listening for signals it should be OK.

However, I don't think the postmaster reads/writes PROC so we would need
some other way of flagging the backend. I bet there is some Win32 API
that might help us.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073