Re: Signals inheritance work - major problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Signals inheritance work - major problems
Date: 2004-11-03 20:43:45
Message-ID: 16737.1099514625@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

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

In response to

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2004-11-03 21:31:23 Re: Edit query buffer
Previous Message Bruce Momjian 2004-11-03 20:37:01 Re: Signals inheritance work - major problems