diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-06-19 14:23:39 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-06-19 14:23:39 -0400 |
| commit | 48913db887e6a41fa3f1b6cdf80ee89e38f21d9d (patch) | |
| tree | 9961e708c2972a39ae1274d96fa2d8e2de408ed9 /doc/src | |
| parent | da1a9d0f5bed1f93908be9233a4fef39b988e505 (diff) | |
In immediate shutdown, postmaster should not exit till children are gone.
This adjusts commit 82233ce7ea42d6ba519aaec63008aff49da6c7af so that the
postmaster does not exit until all its child processes have exited, even
if the 5-second timeout elapses and we have to send SIGKILL. There is no
great value in having the postmaster process quit sooner, and doing so can
mislead onlookers into thinking that the cluster is fully terminated when
actually some child processes still survive.
This effect might explain recent test failures on buildfarm member hamster,
wherein we failed to restart a cluster just after shutting it down with
"pg_ctl stop -m immediate".
I also did a bit of code review/beautification, including fixing a faulty
use of the Max() macro on a volatile expression.
Back-patch to 9.4. In older branches, the postmaster never waited for
children to exit during immediate shutdowns, and changing that would be
too much of a behavioral change.
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/runtime.sgml | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 026850a1cf5..dacd3e1dfef 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1441,10 +1441,11 @@ $ <userinput>sysctl -w vm.nr_hugepages=3170</userinput> <para> This is the <firstterm>Immediate Shutdown</firstterm> mode. The server will send <systemitem>SIGQUIT</systemitem> to all child - processes and wait for them to terminate. Those that don't terminate - within 5 seconds, will be sent <systemitem>SIGKILL</systemitem> by the - master <command>postgres</command> process, which will then terminate - without further waiting. This will lead to recovery (by + processes and wait for them to terminate. If any do not terminate + within 5 seconds, they will be sent <systemitem>SIGKILL</systemitem>. + The master server process exits as soon as all child processes have + exited, without doing normal database shutdown processing. + This will lead to recovery (by replaying the WAL log) upon next start-up. This is recommended only in emergencies. </para> |