Re: [pgsql-hackers-win32] Win32 lost signals open item

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 02:43:08
Message-ID: 200411010243.iA12h8c20014@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-11-01 04:00:06 Re: [PATCHES] Open Items
Previous Message Tom Lane 2004-11-01 02:34:47 Re: [pgsql-hackers-win32] Win32 lost signals open item

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message yuvaraj duraisamy 2004-11-01 19:56:11 PostgreSQL 8.0.0-beta4 Windows 2000 Installation
Previous Message Tom Lane 2004-11-01 02:34:47 Re: [pgsql-hackers-win32] Win32 lost signals open item