RE: SIGQUIT on archiver child processes maybe not such a hot idea? - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: SIGQUIT on archiver child processes maybe not such a hot idea?
Date
Msg-id 0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05
Whole thread Raw
In response to Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Re: SIGQUIT on archiver child processes maybe not such a hot idea?
List 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 by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: Bug in GiST paring heap comparator
Next
From: "Jonathan S. Katz"
Date:
Subject: PG12 Beta 4 Press Release