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

Re: smart shutdown at end of transaction (was: Default mode for shutdown)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Date: 2012-04-27 22:09:56
Message-ID: 29545.1335564596@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)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.  So I think
choice #2 is not sensible at all.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2012-04-27 22:18:38
Subject: Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
Previous:From: Bruce MomjianDate: 2012-04-27 21:47:36
Subject: Re: 9.2 release notes, beta time?

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