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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-04-27 22:18:38 | Re: Re: xReader, double-effort (was: Temporary tables under hot standby) |
Previous Message | Bruce Momjian | 2012-04-27 21:47:36 | Re: 9.2 release notes, beta time? |