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 0A3221C70F24FB45833433255569204D1FD3366B@G01JPEXMBYT05
Whole thread Raw
In response to Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (David Steele <david@pgmasters.net>)
List pgsql-hackers
From: David Steele [mailto:david@pgmasters.net]
> > 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.
> 
> -1, at least not immediately.  Archivers can be complex processes and
> they should be given the chance to do a graceful shutdown.

I agree that the user's archiver program should receive the chance for graceful stop in smart or fast shutdown.  But I
thinkin immediate shutdown, all should stop immediately.  That's what I expect from the word "immediate."
 

If the grandchildren left running don't disturb the cleanup of PostgreSQL's resources (shared memory, file/directory
access,etc.) or restart of PostgreSQL, we may well be able to just advice the grandchildren to stop immediately with
SIGINT/SIGTERM. However, for example, in the failover of shared-disk HA clustering, when the clustering software stops
PostgreSQLwith "pg_ctl stop -m immediate" and then tries to unmount the file systems for $PGDATA and archived WAL, the
unmount may take time or fail due to the access from PostgreSQL's grandchildren.
 


Regards
Takayuki Tsunakawa





pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Next
From: Michael Paquier
Date:
Subject: Re: [bug fix] Produce a crash dump before main() on Windows