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

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Дата
Msg-id 20190911.110124.96874741.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на RE: SIGQUIT on archiver child processes maybe not such a hot idea?  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
At Wed, 11 Sep 2019 01:36:15 +0000, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com> wrote in
<0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05>
> From: Tom Lane [mailto:tgl@sss.pgh.pa.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
postmasteris 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
ignoreSIGINT/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
separatetopic.)
 

reagards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: PG12 Beta 4 Press Release
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: MSVC buildfarm critters are not running modules' TAP tests