Re: Signals inheritance work - major problems - Mailing list pgsql-hackers-win32

From Tom Lane
Subject Re: Signals inheritance work - major problems
Date
Msg-id 16737.1099514625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Signals inheritance work - major problems  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers-win32
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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 doesn't really help, because we do not want to have to interpret
any command-line stuff at the very top of main.c.  The signals thread
start has to be moved to someplace after we've parsed the command line.
(There isn't any harm in doing so, because we'd ordinarily not open up
the signal mask to accept signals until long after that anyway.)

Also, if the pipe name isn't based on the PID, how the heck are other
processes going to implement kill()?  They won't have any way to
translate a PID into some random counter value.

> This would prevent pg_ctl kill from working (it doesn't know the counter
> value)

Not to mention NOTIFY, SendPostmasterSignal, RequestCheckpoint, and
probably a few other things that escape me at the moment.

            regards, tom lane

pgsql-hackers-win32 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Signals inheritance work - major problems
Next
From: Tom Lane
Date:
Subject: Re: Edit query buffer