Thread: Use SIGQUIT instead of SIGUSR1?
To implement the idea of performing a checkpoint after every so many
XLOG megabytes (as well as after every so many seconds), I need to pick
an additional signal number for the postmaster to accept. Seems like
the most appropriate choice for this is SIGUSR1, which isn't currently
being used at the postmaster level.
However, if I just do that, then SIGUSR1 and SIGQUIT will have
completely different meanings for the postmaster and for the backends,
in fact SIGQUIT to the postmaster means send SIGUSR1 to the backends.
This seems hopelessly confusing.
I think it'd be a good idea to change the code so that SIGQUIT is the
per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and
backend signals back into some semblance of agreement.
For the moment we could leave the backends also accepting SIGUSR1 as
quickdie, just in case someone out there is in the habit of sending
that signal manually to individual backends. Eventually backend SIGUSR1
might be reassigned to mean something else. (I suspect Bruce is
coveting it already ;-).)
Any objections?
regards, tom lane
On Thu, Mar 08, 2001 at 04:06:16PM -0500, Tom Lane wrote: > To implement the idea of performing a checkpoint after every so many > XLOG megabytes (as well as after every so many seconds), I need to pick > an additional signal number for the postmaster to accept. Seems like > the most appropriate choice for this is SIGUSR1, which isn't currently > being used at the postmaster level. > > However, if I just do that, then SIGUSR1 and SIGQUIT will have > completely different meanings for the postmaster and for the backends, > in fact SIGQUIT to the postmaster means send SIGUSR1 to the backends. > This seems hopelessly confusing. > > I think it'd be a good idea to change the code so that SIGQUIT is the > per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and > backend signals back into some semblance of agreement. > > For the moment we could leave the backends also accepting SIGUSR1 as > quickdie, just in case someone out there is in the habit of sending > that signal manually to individual backends. Eventually backend SIGUSR1 > might be reassigned to mean something else. (I suspect Bruce is > coveting it already ;-).) The number and variety of signals used in PG is already terrifying. Attaching a specific meaning to SIGQUIT may be dangerous if the OS and its daemons also send SIGQUIT to mean something subtly different. I'd rather see a reduction in the use of signals, and a movement toward more modern, better behaved interprocess communication mechanisms. Still, "if it were done when 'tis done, then 'twere well It were done" cleanly. -- Nathan Myers ncm@zembu.com
Tom Lane writes: > I think it'd be a good idea to change the code so that SIGQUIT is the > per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and > backend signals back into some semblance of agreement. I think we agreed on this already when someone wanted to use a signal for synchronizing "near-committers". Still seems like a good idea. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
ncm@zembu.com (Nathan Myers) writes:
> On Thu, Mar 08, 2001 at 04:06:16PM -0500, Tom Lane wrote:
>> I think it'd be a good idea to change the code so that SIGQUIT is the
>> per-backend quickdie() signal, not SIGUSR1, to bring the postmaster and
>> backend signals back into some semblance of agreement.
> The number and variety of signals used in PG is already terrifying.
> Attaching a specific meaning to SIGQUIT may be dangerous if the OS and
> its daemons also send SIGQUIT to mean something subtly different.
Quite true. One additional reason for this change is to make SIGQUIT
do something a little closer to what one would expect, ie, force-quit
the backend, and in particular to ensure that SIGQUIT'ing the whole
postmaster-and-backends process group produces a reasonable result.
We've been gradually rationalizing the signal usage over the last few
releases, and this is another step in the process.
regards, tom lane