Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit b4d8be9

Browse filesBrowse 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 e590211 commit b4d8be9
Copy full SHA for b4d8be9

File tree

Expand file treeCollapse file tree

4 files changed

+126
-121
lines changed
Filter options
Expand file treeCollapse file tree

4 files changed

+126
-121
lines changed

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

Copy file name to clipboardExpand all lines: doc/src/sgml/ref/pg_ctl-ref.sgml
+2-2Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -173,8 +173,8 @@ PostgreSQL documentation
173173
In <option>stop</option> mode, the server that is running in
174174
the specified data directory is shut down. Three different
175175
shutdown methods can be selected with the <option>-m</option>
176-
option. <quote>Smart</quote> mode waits for all active
177-
clients to disconnect and any online backup to finish.
176+
option. <quote>Smart</quote> mode disallows new connections, then waits
177+
for all existing clients to disconnect and any online backup to finish.
178178
If the server is in hot standby, recovery and streaming replication
179179
will be terminated once all clients have disconnected.
180180
<quote>Fast</quote> mode (the default) does not wait for clients to disconnect and

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.