Re: SIGQUIT on archiver child processes maybe not such a hot idea?

At Wed, 11 Sep 2019 01:36:15 +0000, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote in <0A3221C70F24FB45833433255569204D1FD33579(at)G01JPEXMBYT05>
> 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.

Perhaps +1.. immediate -> SIGKILL fast -> SIGTERM?

> (Windows cannot stop grandchildren because kill() in src/port/kill.c doesn't support the process group... That's a separate topic.)

reagards.

--
Kyotaro Horiguchi
NTT Open Source Software Center