Use SIGQUIT instead of SIGUSR1?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Use SIGQUIT instead of SIGUSR1?
Date: 2001-03-08 21:06:16
Message-ID: 124.984085576@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew Hagerty 2001-03-08 21:14:08 Is INSERT FROM considered a transaction?
Previous Message Richard Poole 2001-03-08 20:38:33 Re: Query not using index, please explain.