| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SIGQUIT on archiver child processes maybe not such a hot idea? |
| Date: | 2019-09-11 02:11:52 |
| Message-ID: | 91ac67ee-0bda-9289-e3bf-ef33a1d3b6be@pgmasters.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/10/19 9:36 PM, Tsunakawa, Takayuki wrote:
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> SIGTERM, which needs to be adjusted. For another, its
>> SIGQUIT handler does exit(1) not _exit(2), which seems rather
>> dubious ... should we make it more like the rest? I think
>> the reasoning there might've been that if some DBA decides to
>> SIGQUIT the archiver, we don't need to force a database-wide
>> reset; but why exactly should we tolerate that?
>
> Can't we use SIGKILL instead of SIGINT/SIGTERM to stop the grandchildren, just in case they are slow to respond to or ignore SIGINT/SIGTERM? That matches the idea of pg_ctl's immediate shutdown.
-1, at least not immediately. Archivers can be complex processes and
they should be given the chance to do a graceful shutdown.
Regards,
--
-David
david(at)pgmasters(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2019-09-11 02:34:59 | RE: SIGQUIT on archiver child processes maybe not such a hot idea? |
| Previous Message | Michael Paquier | 2019-09-11 02:11:35 | Re: MSVC buildfarm critters are not running modules' TAP tests |