Re: smart shutdown at end of transaction (was: Default mode for shutdown) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Date
Msg-id 1335606301.21838.5.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: smart shutdown at end of transaction (was: Default mode for shutdown)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On fre, 2012-04-27 at 18:09 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > It seems we need another signal for the new mode, and the obvious
> > candidate is SIGUSR2.  But what shall the mapping look like?
> 
> > [Choice #1] SIGUSR2 -> slow, SIGTERM -> smart, SIGINT -> fast, SIGQUIT
> > -> immediate
> > [Choice #2] SIGTERM -> slow, SIGUSR2 -> smart, SIGINT -> fast, SIGQUIT
> > -> immediate
> 
> SIGTERM needs to correspond to a fairly aggressive shutdown mode,
> since (at least on some systems) init will send that during the system
> shutdown sequence, shortly before escalating to SIGKILL.

That only happens if the postgresql init script itself didn't do a good
job.  We already have this setup currently, and it doesn't seem to cause
a great deal of problems.

> If we were willing to consider wholesale breakage of any scripts that
> send these signals directly, I'd almost consider that it should be
> SIGUSR2, SIGINT, SIGTERM, SIGQUIT.  But that might be more churn than
> we want.  Keeping SIGTERM attached to the default/"smart" shutdown mode
> seems like a reasonable compromise.

I don't think we should change the traditional "severity" order of
signals.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Next
From: Simon Riggs
Date:
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)