RE: SIGQUIT on archiver child processes maybe not such a hot idea?
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: SIGQUIT on archiver child processes maybe not such a hot idea? |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: SIGQUIT on archiver child processes maybe not such a hot idea? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Re: SIGQUIT on archiver child processes maybe not such a hot idea? |
Список | pgsql-hackers |
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. (Windows cannot stop grandchildren because kill() in src/port/kill.c doesn't support the process group... That's a separatetopic.) Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: