From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | David Steele <david(at)pgmasters(dot)net>, 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 01:36:15 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
postmaster doesn't distinguish return codes other than 0 for the archiver, and just starts the archiver unless postmaster is shutting down. So we can use _exit(2) like the other children.
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.
(Windows cannot stop grandchildren because kill() in src/port/kill.c doesn't support the process group... That's a separate topic.)
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2019-09-11 01:37:33 | PG12 Beta 4 Press Release |
Previous Message | Nikita Glukhov | 2019-09-11 00:31:34 | Re: Bug in GiST paring heap comparator |