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
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 |
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 |