4 19.6.1. Sending Servers
6 19.6.3. Standby Servers
9 These settings control the behavior of the built-in streaming
10 replication feature (see Section 26.2.5), and the built-in logical
11 replication feature (see Chapter 29).
13 For streaming replication, servers will be either a primary or a
14 standby server. Primaries can send data, while standbys are always
15 receivers of replicated data. When cascading replication (see
16 Section 26.2.7) is used, standby servers can also be senders, as well
17 as receivers. Parameters are mainly for sending and standby servers,
18 though some parameters have meaning only on the primary server.
19 Settings may vary across the cluster without problems if that is
22 For logical replication, publishers (servers that do CREATE
23 PUBLICATION) replicate data to subscribers (servers that do CREATE
24 SUBSCRIPTION). Servers can also be publishers and subscribers at the
25 same time. Note, the following sections refer to publishers as
26 "senders". For more details about logical replication configuration
27 settings refer to Section 29.12.
29 19.6.1. Sending Servers #
31 These parameters can be set on any server that is to send replication
32 data to one or more standby servers. The primary is always a sending
33 server, so these parameters must always be set on the primary. The role
34 and meaning of these parameters does not change after a standby becomes
37 max_wal_senders (integer) #
38 Specifies the maximum number of concurrent connections from
39 standby servers or streaming base backup clients (i.e., the
40 maximum number of simultaneously running WAL sender processes).
41 The default is 10. The value 0 means replication is disabled.
42 Abrupt disconnection of a streaming client might leave an
43 orphaned connection slot behind until a timeout is reached, so
44 this parameter should be set slightly higher than the maximum
45 number of expected clients so disconnected clients can
46 immediately reconnect. This parameter can only be set at server
47 start. Also, wal_level must be set to replica or higher to allow
48 connections from standby servers.
50 When running a standby server, you must set this parameter to
51 the same or higher value than on the primary server. Otherwise,
52 queries will not be allowed in the standby server.
54 max_replication_slots (integer) #
55 Specifies the maximum number of replication slots (see
56 Section 26.2.6) that the server can support. The default is 10.
57 This parameter can only be set at server start. Setting it to a
58 lower value than the number of currently existing replication
59 slots will prevent the server from starting. Also, wal_level
60 must be set to replica or higher to allow replication slots to
63 wal_keep_size (integer) #
64 Specifies the minimum size of past WAL files kept in the pg_wal
65 directory, in case a standby server needs to fetch them for
66 streaming replication. If a standby server connected to the
67 sending server falls behind by more than wal_keep_size
68 megabytes, the sending server might remove a WAL segment still
69 needed by the standby, in which case the replication connection
70 will be terminated. Downstream connections will also eventually
71 fail as a result. (However, the standby server can recover by
72 fetching the segment from archive, if WAL archiving is in use.)
74 This sets only the minimum size of segments retained in pg_wal;
75 the system might need to retain more segments for WAL archival
76 or to recover from a checkpoint. If wal_keep_size is zero (the
77 default), the system doesn't keep any extra segments for standby
78 purposes, so the number of old WAL segments available to standby
79 servers is a function of the location of the previous checkpoint
80 and status of WAL archiving. If this value is specified without
81 units, it is taken as megabytes. This parameter can only be set
82 in the postgresql.conf file or on the server command line.
84 max_slot_wal_keep_size (integer) #
85 Specify the maximum size of WAL files that replication slots are
86 allowed to retain in the pg_wal directory at checkpoint time. If
87 max_slot_wal_keep_size is -1 (the default), replication slots
88 may retain an unlimited amount of WAL files. Otherwise, if
89 restart_lsn of a replication slot falls behind the current LSN
90 by more than the given size, the standby using the slot may no
91 longer be able to continue replication due to removal of
92 required WAL files. You can see the WAL availability of
93 replication slots in pg_replication_slots. If this value is
94 specified without units, it is taken as megabytes. This
95 parameter can only be set in the postgresql.conf file or on the
98 idle_replication_slot_timeout (integer) #
99 Invalidate replication slots that have remained inactive (not
100 used by a replication connection) for longer than this duration.
101 If this value is specified without units, it is taken as
102 seconds. A value of zero (the default) disables the idle timeout
103 invalidation mechanism. This parameter can only be set in the
104 postgresql.conf file or on the server command line.
106 Slot invalidation due to idle timeout occurs during checkpoint.
107 Because checkpoints happen at checkpoint_timeout intervals,
108 there can be some lag between when the
109 idle_replication_slot_timeout was exceeded and when the slot
110 invalidation is triggered at the next checkpoint. To avoid such
111 lags, users can force a checkpoint to promptly invalidate
112 inactive slots. The duration of slot inactivity is calculated
113 using the slot's pg_replication_slots.inactive_since value.
115 Note that the idle timeout invalidation mechanism is not
116 applicable for slots that do not reserve WAL or for slots on the
117 standby server that are being synced from the primary server
118 (i.e., standby slots having pg_replication_slots.synced value
119 true). Synced slots are always considered to be inactive because
120 they don't perform logical decoding to produce changes.
122 wal_sender_timeout (integer) #
123 Terminate replication connections that are inactive for longer
124 than this amount of time. This is useful for the sending server
125 to detect a standby crash or network outage. If this value is
126 specified without units, it is taken as milliseconds. The
127 default value is 60 seconds. A value of zero disables the
130 With a cluster distributed across multiple geographic locations,
131 using different values per location brings more flexibility in
132 the cluster management. A smaller value is useful for faster
133 failure detection with a standby having a low-latency network
134 connection, and a larger value helps in judging better the
135 health of a standby if located on a remote location, with a
136 high-latency network connection.
138 track_commit_timestamp (boolean) #
139 Record commit time of transactions. This parameter can only be
140 set in postgresql.conf file or on the server command line. The
141 default value is off.
143 synchronized_standby_slots (string) #
144 A comma-separated list of streaming replication standby server
145 slot names that logical WAL sender processes will wait for.
146 Logical WAL sender processes will send decoded changes to
147 plugins only after the specified replication slots confirm
148 receiving WAL. This guarantees that logical replication failover
149 slots do not consume changes until those changes are received
150 and flushed to corresponding physical standbys. If a logical
151 replication connection is meant to switch to a physical standby
152 after the standby is promoted, the physical replication slot for
153 the standby should be listed here. Note that logical replication
154 will not proceed if the slots specified in the
155 synchronized_standby_slots do not exist or are invalidated.
156 Additionally, the replication management functions
157 pg_replication_slot_advance, pg_logical_slot_get_changes, and
158 pg_logical_slot_peek_changes, when used with logical failover
159 slots, will block until all physical slots specified in
160 synchronized_standby_slots have confirmed WAL receipt.
162 The standbys corresponding to the physical replication slots in
163 synchronized_standby_slots must configure sync_replication_slots
164 = true so they can receive logical failover slot changes from
167 19.6.2. Primary Server #
169 These parameters can be set on the primary server that is to send
170 replication data to one or more standby servers. Note that in addition
171 to these parameters, wal_level must be set appropriately on the primary
172 server, and optionally WAL archiving can be enabled as well (see
173 Section 19.5.3). The values of these parameters on standby servers are
174 irrelevant, although you may wish to set them there in preparation for
175 the possibility of a standby becoming the primary.
177 synchronous_standby_names (string) #
178 Specifies a list of standby servers that can support synchronous
179 replication, as described in Section 26.2.8. There will be one
180 or more active synchronous standbys; transactions waiting for
181 commit will be allowed to proceed after these standby servers
182 confirm receipt of their data. The synchronous standbys will be
183 those whose names appear in this list, and that are both
184 currently connected and streaming data in real-time (as shown by
185 a state of streaming in the pg_stat_replication view).
186 Specifying more than one synchronous standby can allow for very
187 high availability and protection against data loss.
189 The name of a standby server for this purpose is the
190 application_name setting of the standby, as set in the standby's
191 connection information. In case of a physical replication
192 standby, this should be set in the primary_conninfo setting; the
193 default is the setting of cluster_name if set, else walreceiver.
194 For logical replication, this can be set in the connection
195 information of the subscription, and it defaults to the
196 subscription name. For other replication stream consumers,
197 consult their documentation.
199 This parameter specifies a list of standby servers using either
200 of the following syntaxes:
202 [FIRST] num_sync ( standby_name [, ...] )
203 ANY num_sync ( standby_name [, ...] )
206 where num_sync is the number of synchronous standbys that
207 transactions need to wait for replies from, and standby_name is
208 the name of a standby server. num_sync must be an integer value
209 greater than zero. FIRST and ANY specify the method to choose
210 synchronous standbys from the listed servers.
212 The keyword FIRST, coupled with num_sync, specifies a
213 priority-based synchronous replication and makes transaction
214 commits wait until their WAL records are replicated to num_sync
215 synchronous standbys chosen based on their priorities. For
216 example, a setting of FIRST 3 (s1, s2, s3, s4) will cause each
217 commit to wait for replies from three higher-priority standbys
218 chosen from standby servers s1, s2, s3 and s4. The standbys
219 whose names appear earlier in the list are given higher priority
220 and will be considered as synchronous. Other standby servers
221 appearing later in this list represent potential synchronous
222 standbys. If any of the current synchronous standbys disconnects
223 for whatever reason, it will be replaced immediately with the
224 next-highest-priority standby. The keyword FIRST is optional.
226 The keyword ANY, coupled with num_sync, specifies a quorum-based
227 synchronous replication and makes transaction commits wait until
228 their WAL records are replicated to at least num_sync listed
229 standbys. For example, a setting of ANY 3 (s1, s2, s3, s4) will
230 cause each commit to proceed as soon as at least any three
231 standbys of s1, s2, s3 and s4 reply.
233 FIRST and ANY are case-insensitive. If these keywords are used
234 as the name of a standby server, its standby_name must be
237 The third syntax was used before PostgreSQL version 9.6 and is
238 still supported. It's the same as the first syntax with FIRST
239 and num_sync equal to 1. For example, FIRST 1 (s1, s2) and s1,
240 s2 have the same meaning: either s1 or s2 is chosen as a
243 The special entry * matches any standby name.
245 There is no mechanism to enforce uniqueness of standby names. In
246 case of duplicates one of the matching standbys will be
247 considered as higher priority, though exactly which one is
252 Each standby_name should have the form of a valid SQL
253 identifier, unless it is *. You can use double-quoting if
254 necessary. But note that standby_names are compared to standby
255 application names case-insensitively, whether double-quoted or
258 If no synchronous standby names are specified here, then
259 synchronous replication is not enabled and transaction commits
260 will not wait for replication. This is the default
261 configuration. Even when synchronous replication is enabled,
262 individual transactions can be configured not to wait for
263 replication by setting the synchronous_commit parameter to local
266 This parameter can only be set in the postgresql.conf file or on
267 the server command line.
269 19.6.3. Standby Servers #
271 These settings control the behavior of a standby server that is to
272 receive replication data. Their values on the primary server are
275 primary_conninfo (string) #
276 Specifies a connection string to be used for the standby server
277 to connect with a sending server. This string is in the format
278 described in Section 32.1.1. If any option is unspecified in
279 this string, then the corresponding environment variable (see
280 Section 32.15) is checked. If the environment variable is not
281 set either, then defaults are used.
283 The connection string should specify the host name (or address)
284 of the sending server, as well as the port number if it is not
285 the same as the standby server's default. Also specify a user
286 name corresponding to a suitably-privileged role on the sending
287 server (see Section 26.2.5.1). A password needs to be provided
288 too, if the sender demands password authentication. It can be
289 provided in the primary_conninfo string, or in a separate
290 ~/.pgpass file on the standby server (use replication as the
293 For replication slot synchronization (see Section 47.2.3), it is
294 also necessary to specify a valid dbname in the primary_conninfo
295 string. This will only be used for slot synchronization. It is
296 ignored for streaming.
298 This parameter can only be set in the postgresql.conf file or on
299 the server command line. If this parameter is changed while the
300 WAL receiver process is running, that process is signaled to
301 shut down and expected to restart with the new setting (except
302 if primary_conninfo is an empty string). This setting has no
303 effect if the server is not in standby mode.
305 primary_slot_name (string) #
306 Optionally specifies an existing replication slot to be used
307 when connecting to the sending server via streaming replication
308 to control resource removal on the upstream node (see
309 Section 26.2.6). This parameter can only be set in the
310 postgresql.conf file or on the server command line. If this
311 parameter is changed while the WAL receiver process is running,
312 that process is signaled to shut down and expected to restart
313 with the new setting. This setting has no effect if
314 primary_conninfo is not set or the server is not in standby
317 hot_standby (boolean) #
318 Specifies whether or not you can connect and run queries during
319 recovery, as described in Section 26.4. The default value is on.
320 This parameter can only be set at server start. It only has
321 effect during archive recovery or in standby mode.
323 max_standby_archive_delay (integer) #
324 When hot standby is active, this parameter determines how long
325 the standby server should wait before canceling standby queries
326 that conflict with about-to-be-applied WAL entries, as described
327 in Section 26.4.2. max_standby_archive_delay applies when WAL
328 data is being read from WAL archive (and is therefore not
329 current). If this value is specified without units, it is taken
330 as milliseconds. The default is 30 seconds. A value of -1 allows
331 the standby to wait forever for conflicting queries to complete.
332 This parameter can only be set in the postgresql.conf file or on
333 the server command line.
335 Note that max_standby_archive_delay is not the same as the
336 maximum length of time a query can run before cancellation;
337 rather it is the maximum total time allowed to apply any one WAL
338 segment's data. Thus, if one query has resulted in significant
339 delay earlier in the WAL segment, subsequent conflicting queries
340 will have much less grace time.
342 max_standby_streaming_delay (integer) #
343 When hot standby is active, this parameter determines how long
344 the standby server should wait before canceling standby queries
345 that conflict with about-to-be-applied WAL entries, as described
346 in Section 26.4.2. max_standby_streaming_delay applies when WAL
347 data is being received via streaming replication. If this value
348 is specified without units, it is taken as milliseconds. The
349 default is 30 seconds. A value of -1 allows the standby to wait
350 forever for conflicting queries to complete. This parameter can
351 only be set in the postgresql.conf file or on the server command
354 Note that max_standby_streaming_delay is not the same as the
355 maximum length of time a query can run before cancellation;
356 rather it is the maximum total time allowed to apply WAL data
357 once it has been received from the primary server. Thus, if one
358 query has resulted in significant delay, subsequent conflicting
359 queries will have much less grace time until the standby server
362 wal_receiver_create_temp_slot (boolean) #
363 Specifies whether the WAL receiver process should create a
364 temporary replication slot on the remote instance when no
365 permanent replication slot to use has been configured (using
366 primary_slot_name). The default is off. This parameter can only
367 be set in the postgresql.conf file or on the server command
368 line. If this parameter is changed while the WAL receiver
369 process is running, that process is signaled to shut down and
370 expected to restart with the new setting.
372 wal_receiver_status_interval (integer) #
373 Specifies the minimum frequency for the WAL receiver process on
374 the standby to send information about replication progress to
375 the primary or upstream standby, where it can be seen using the
376 pg_stat_replication view. The standby will report the last
377 write-ahead log location it has written, the last position it
378 has flushed to disk, and the last position it has applied. This
379 parameter's value is the maximum amount of time between reports.
380 Updates are sent each time the write or flush positions change,
381 or as often as specified by this parameter if set to a non-zero
382 value. There are additional cases where updates are sent while
383 ignoring this parameter; for example, when processing of the
384 existing WAL completes or when synchronous_commit is set to
385 remote_apply. Thus, the apply position may lag slightly behind
386 the true position. If this value is specified without units, it
387 is taken as seconds. The default value is 10 seconds. This
388 parameter can only be set in the postgresql.conf file or on the
391 hot_standby_feedback (boolean) #
392 Specifies whether or not a hot standby will send feedback to the
393 primary or upstream standby about queries currently executing on
394 the standby. This parameter can be used to eliminate query
395 cancels caused by cleanup records, but can cause database bloat
396 on the primary for some workloads. Feedback messages will not be
397 sent more frequently than once per wal_receiver_status_interval.
398 The default value is off. This parameter can only be set in the
399 postgresql.conf file or on the server command line.
401 If cascaded replication is in use the feedback is passed
402 upstream until it eventually reaches the primary. Standbys make
403 no other use of feedback they receive other than to pass
406 Note that if the clock on standby is moved ahead or backward,
407 the feedback message might not be sent at the required interval.
408 In extreme cases, this can lead to a prolonged risk of not
409 removing dead rows on the primary for extended periods, as the
410 feedback mechanism is based on timestamps.
412 wal_receiver_timeout (integer) #
413 Terminate replication connections that are inactive for longer
414 than this amount of time. This is useful for the receiving
415 standby server to detect a primary node crash or network outage.
416 If this value is specified without units, it is taken as
417 milliseconds. The default value is 60 seconds. A value of zero
418 disables the timeout mechanism. This parameter can only be set
419 in the postgresql.conf file or on the server command line.
421 wal_retrieve_retry_interval (integer) #
422 Specifies how long the standby server should wait when WAL data
423 is not available from any sources (streaming replication, local
424 pg_wal or WAL archive) before trying again to retrieve WAL data.
425 If this value is specified without units, it is taken as
426 milliseconds. The default value is 5 seconds. This parameter can
427 only be set in the postgresql.conf file or on the server command
430 This parameter is useful in configurations where a node in
431 recovery needs to control the amount of time to wait for new WAL
432 data to be available. For example, in archive recovery, it is
433 possible to make the recovery more responsive in the detection
434 of a new WAL file by reducing the value of this parameter. On a
435 system with low WAL activity, increasing it reduces the amount
436 of requests necessary to access WAL archives, something useful
437 for example in cloud environments where the number of times an
438 infrastructure is accessed is taken into account.
440 In logical replication, this parameter also limits how often a
441 failing replication apply worker or table synchronization worker
444 recovery_min_apply_delay (integer) #
445 By default, a standby server restores WAL records from the
446 sending server as soon as possible. It may be useful to have a
447 time-delayed copy of the data, offering opportunities to correct
448 data loss errors. This parameter allows you to delay recovery by
449 a specified amount of time. For example, if you set this
450 parameter to 5min, the standby will replay each transaction
451 commit only when the system time on the standby is at least five
452 minutes past the commit time reported by the primary. If this
453 value is specified without units, it is taken as milliseconds.
454 The default is zero, adding no delay.
456 It is possible that the replication delay between servers
457 exceeds the value of this parameter, in which case no delay is
458 added. Note that the delay is calculated between the WAL time
459 stamp as written on primary and the current time on the standby.
460 Delays in transfer because of network lag or cascading
461 replication configurations may reduce the actual wait time
462 significantly. If the system clocks on primary and standby are
463 not synchronized, this may lead to recovery applying records
464 earlier than expected; but that is not a major issue because
465 useful settings of this parameter are much larger than typical
466 time deviations between servers.
468 The delay occurs only on WAL records for transaction commits.
469 Other records are replayed as quickly as possible, which is not
470 a problem because MVCC visibility rules ensure their effects are
471 not visible until the corresponding commit record is applied.
473 The delay occurs once the database in recovery has reached a
474 consistent state, until the standby is promoted or triggered.
475 After that the standby will end recovery without further
478 WAL records must be kept on the standby until they are ready to
479 be applied. Therefore, longer delays will result in a greater
480 accumulation of WAL files, increasing disk space requirements
481 for the standby's pg_wal directory.
483 This parameter is intended for use with streaming replication
484 deployments; however, if the parameter is specified it will be
485 honored in all cases except crash recovery. hot_standby_feedback
486 will be delayed by use of this feature which could lead to bloat
487 on the primary; use both together with care.
491 Synchronous replication is affected by this setting when
492 synchronous_commit is set to remote_apply; every COMMIT will
493 need to wait to be applied.
495 This parameter can only be set in the postgresql.conf file or on
496 the server command line.
498 sync_replication_slots (boolean) #
499 It enables a physical standby to synchronize logical failover
500 slots from the primary server so that logical subscribers can
501 resume replication from the new primary server after failover.
503 It is disabled by default. This parameter can only be set in the
504 postgresql.conf file or on the server command line.
506 19.6.4. Subscribers #
508 These settings control the behavior of a logical replication
509 subscriber. Their values on the publisher are irrelevant. See
510 Section 29.12 for more details.
512 max_active_replication_origins (integer) #
513 Specifies how many replication origins (see Chapter 48) can be
514 tracked simultaneously, effectively limiting how many logical
515 replication subscriptions can be created on the server. Setting
516 it to a lower value than the current number of tracked
517 replication origins (reflected in pg_replication_origin_status)
518 will prevent the server from starting. It defaults to 10. This
519 parameter can only be set at server start.
520 max_active_replication_origins must be set to at least the
521 number of subscriptions that will be added to the subscriber,
522 plus some reserve for table synchronization.
524 max_logical_replication_workers (integer) #
525 Specifies maximum number of logical replication workers. This
526 includes leader apply workers, parallel apply workers, and table
527 synchronization workers.
529 Logical replication workers are taken from the pool defined by
530 max_worker_processes.
532 The default value is 4. This parameter can only be set at server
535 max_sync_workers_per_subscription (integer) #
536 Maximum number of synchronization workers per subscription. This
537 parameter controls the amount of parallelism of the initial data
538 copy during the subscription initialization or when new tables
541 Currently, there can be only one synchronization worker per
544 The synchronization workers are taken from the pool defined by
545 max_logical_replication_workers.
547 The default value is 2. This parameter can only be set in the
548 postgresql.conf file or on the server command line.
550 max_parallel_apply_workers_per_subscription (integer) #
551 Maximum number of parallel apply workers per subscription. This
552 parameter controls the amount of parallelism for streaming of
553 in-progress transactions with subscription parameter streaming =
556 The parallel apply workers are taken from the pool defined by
557 max_logical_replication_workers.
559 The default value is 2. This parameter can only be set in the
560 postgresql.conf file or on the server command line.
begriffs.com / projects / ai-pg / blob