Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers-win32 by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group