Skip to content

Commit 1c6066f

Browse files
tglsfdctglsfdc
committed
Fix postmaster's behavior during smart shutdown.
Up to now, upon receipt of a SIGTERM ("smart shutdown" command), the postmaster has immediately killed all "optional" background processes, and subsequently refused to launch new ones while it's waiting for foreground client processes to exit. No doubt this seemed like an OK policy at some point; but it's a pretty bad one now, because it makes for a seriously degraded environment for the remaining clients: * Parallel queries are killed, and new ones fail to launch. (And our parallel-query infrastructure utterly fails to deal with the case in a reasonable way --- it just hangs waiting for workers that are not going to arrive. There is more work needed in that area IMO.) * Autovacuum ceases to function. We can tolerate that for awhile, but if bulk-update queries continue to run in the surviving client sessions, there's eventually going to be a mess. In the worst case the system could reach a forced shutdown to prevent XID wraparound. * The bgwriter and walwriter are also stopped immediately, likely resulting in performance degradation. Hence, let's rearrange things so that the only immediate change in behavior is refusing to let in new normal connections. Once the last normal connection is gone, shut everything down as though we'd received a "fast" shutdown. To implement this, remove the PM_WAIT_BACKUP and PM_WAIT_READONLY states, instead staying in PM_RUN or PM_HOT_STANDBY while normal connections remain. A subsidiary state variable tracks whether or not we're letting in new connections in those states. This also allows having just one copy of the logic for killing child processes in smart and fast shutdown modes. I moved that logic into PostmasterStateMachine() by inventing a new state PM_STOP_BACKENDS. Back-patch to 9.6 where parallel query was added. In principle this'd be a good idea in 9.5 as well, but the risk/reward ratio is not as good there, since lack of autovacuum is not a problem during typical uses of smart shutdown. Per report from Bharath Rupireddy. Patch by me, reviewed by Thomas Munro Discussion: https://postgr.es/m/CALj2ACXAZ5vKxT9P7P89D87i3MDO9bfS+_bjMHgnWJs8uwUOOw@mail.gmail.com
1 parent cabec1d commit 1c6066f

File tree

4 files changed

+126
-121
lines changed

4 files changed

+126
-121
lines changed

‎doc/src/sgml/ref/pg_ctl-ref.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -185,8 +185,8 @@ PostgreSQL documentation
185185
<option>stop</option> mode shuts down the server that is running in
186186
the specified data directory. Three different
187187
shutdown methods can be selected with the <option>-m</option>
188-
option. <quote>Smart</quote> mode waits for all active
189-
clients to disconnect and any online backup to finish.
188+
option. <quote>Smart</quote> mode disallows new connections, then waits
189+
for all existing clients to disconnect and any online backup to finish.
190190
If the server is in hot standby, recovery and streaming replication
191191
will be terminated once all clients have disconnected.
192192
<quote>Fast</quote> mode (the default) does not wait for clients to disconnect and

0 commit comments

Comments
 (0)