Re: Signals inheritance work - major problems

Tom Lane wrote:
> "Magnus Hagander" <[email protected]> writes:
> > But if I move the signals initialization code to after the backend file
> > read, that is a *lot* later. This is also *after* the backend has set up
> > it's signal handlers, which will crash if things aren't initialized.
> 
> Hm?  read_backend_variables() happens in SubPostmasterMain(), which
> certainly hasn't yet set up any signal handlers.  (It has done a
> PG_SETMASK, but that could be moved down a few lines if it's a problem;
> but my guess is that you want to do that before starting the signals thread
> anyway.)
> 
> I'd be inclined to think in terms of just moving the
> pgwin32_signal_initialize() call out of main.c and into
> SubPostmasterMain; you'd also need it in PostmasterMain and
> BootstrapMain I suppose, but that's not as bad as any of the
> alternatives you mention.

I talked to Magnus via chat and I suggested there was little reason to
have the pipe name be based on the process id.  Rather a single counter
could be used that is passed on the command line or in the config file
and that can be used to create the pipe in the child so process creation
can be cleaner.  The parent can create the pipe and queue up any signals
in there until the child opens the other end.

This would prevent pg_ctl kill from working (it doesn't know the counter
value) but talking to Magnus there is little reason to have pg_ctl kill
work because we don't support admins sending termination signals to
individual backends anyway.

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html