{"Entry":{"collection":"guc","key":"recovery_min_apply_delay","name":"recovery_min_apply_delay","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Standby Servers","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"11","status":"added","to":"12"},{"documentation_changed":true,"fields":{},"from":"13","status":"changed","to":"14"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"},{"documentation_changed":true,"fields":{},"from":"18","status":"changed","to":"19"}],"content_hash":"51b7a7451bbfd75ab27a1233986049ebf0de234bc26998bd285bfcd6cccae1f6","context":"","default_changed_in":[],"default_history":[{"from":"12","to":"19","value":"0 ms"}],"derived_content_hash":"853c6f21efc5c4bafb6b5695b1880b46bbb30e2532bce862257589ea23ff73f5","documentation_refresh":{"batch":"20261113","original_source_rev":"wiki-repair-20261023:559663fa4b3be19d7d8daa12d62f372e9e265c036cf87e077fa945b6bffd2a17","versions":{"14":"14.25","15":"15.20","16":"16.16","17":"17.12","18":"18.7","19":"19rc2"}},"editorial":{"advice":{"olap":"Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.","oltp":"Size recovery_min_apply_delay from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.","small":"Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability."},"mechanism":["Sets the minimum delay for applying changes during recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.","A standby delays replay of each transaction commit until the configured time has elapsed since the primary's commit timestamp. Network/cascade lag counts toward the delay, clocks matter, and synchronous_commit=remote_apply makes primary commits wait through the intentional delay.","Monitor and change recovery_min_apply_delay together with max_standby_archive_delay, max_standby_streaming_delay, hot_standby. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value."],"pitfalls":["Changing it on the wrong primary, standby, sender, or subscriber role.","Watching only configured bytes/time instead of actual lag, slot position, and worker state.","Failing over to a node that lacks the old primary's capacity or prerequisites.","Using infinite waits or WAL retention to hide a failed consumer."],"references":[{"title":"PostgreSQL 19 Beta 4: recovery_min_apply_delay","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-RECOVERY-MIN-APPLY-DELAY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_standby_archive_delay","max_standby_streaming_delay","hot_standby","hot_standby_feedback","primary_conninfo","primary_slot_name"],"summary":"recovery_min_apply_delay sets the minimum delay for applying changes during recovery. It is a sighup setting present in PG12–18; the latest recorded boot default is 0 ms."},"enumvals":[],"first_version":"12","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.865996+08:00","intro_commit":{"authored_at":"2018-11-25T16:31:16+01:00","discussion":["https://www.postgresql.org/message-id/flat/607741529606767@web3g.yandex.ru/"],"hash":"2dedf4d9a899b36d1a8ed29be5efbd1b31a8fe85","subject":"Integrate recovery.conf into postgresql.conf","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2dedf4d9a899b36d1a8ed29be5efbd1b31a8fe85"},"key":"recovery_min_apply_delay","last_version":"20","max_val":"","min_val":"","name":"recovery_min_apply_delay","position":323,"present_in":["12","13","14","15","16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:6cb80f740dea73d0e42e77373aac0308a720969f8043617e6b469b4a0b279ea9","receipt_sha256":"55f47d4e9f98aa6eae655e439bc9a97281ba0be859d5c5be05e21d76b1c9883c","repair":"wiki-repair-20261023"},"short_desc":"By default, a standby server restores WAL records from the sending server as soon as possible.","short_desc_zh":"","source_rev":"wiki-repair-20261023:559663fa4b3be19d7d8daa12d62f372e9e265c036cf87e077fa945b6bffd2a17","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"recovery_min_apply_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"recovery_min_apply_delay","SourceRevision":"wiki-repair-20261023:559663fa4b3be19d7d8daa12d62f372e9e265c036cf87e077fa945b6bffd2a17","Facts":{"boot_val":"0","category":"Replication / Standby Servers","context":"sighup","description":"By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to 5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the primary. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay. It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on primary and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on primary and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers. The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied. The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting. WAL records must be kept on the standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's pg_wal directory. This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases except crash recovery. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the primary; use both together with care. Warning Synchronous replication is affected by this setting when synchronous_commit is set to remote_apply; every COMMIT will need to wait to be applied. This parameter can only be set in the postgresql.conf file or on the server command line.","description_zh":"默认情况下，备库会尽快恢复来自发送服务器的 WAL 记录。保留一份延迟的数据副本可能很有用，因为它提供了纠正数据丢失错误的机会。此参数允许将恢复延迟指定的时间。例如，将此参数设置为 5min 时，只有当备库系统时间比主库报告的提交时间至少晚五分钟，备库才会重放各事务的提交。如果没有指定单位，则以毫秒计。默认值为零，不增加延迟。 服务器之间的复制延迟可能超过此参数的值，这种情况下不会增加延迟。注意，延迟根据主库写入的 WAL 时间戳与备库当前时间之差计算。网络延迟或级联复制配置导致的传输延迟，可能显著缩短实际等待时间。如果主库和备库的系统时钟不同步，恢复时可能比预期更早应用记录；但这通常不是主要问题，因为此参数的实用取值远大于服务器间常见的时间偏差。 延迟仅发生在事务提交的 WAL 记录上。其他记录会尽快重放；这不会造成问题，因为 MVCC 可见性规则确保在对应提交记录被应用之前，它们的效果不会可见。 恢复中的数据库达到一致状态后开始延迟，直到备库被提升或触发。此后，备库会结束恢复，不再等待。 WAL 记录必须保留在备库上，直到可以应用它们。因此，更长的延迟会导致更多 WAL 文件积压，增加备库 pg_wal 目录所需的磁盘空间。 此参数旨在用于流复制部署；不过，只要指定了此参数，它就会在除崩溃恢复以外的所有情况下生效。使用此功能也会延迟 hot_standby_feedback，可能导致主库膨胀；同时使用两者时应谨慎。 警告 当 synchronous_commit 设置为 remote_apply 时，同步复制会受到此设置影响；每个 COMMIT 都必须等待提交被应用。 此参数只能在 postgresql.conf 文件中或服务器命令行上设置。","description_zh_html":"\u003cp\u003e\n        默认情况下，备库会尽快恢复来自发送服务器的 WAL 记录。保留一份延迟的数据副本可能很有用，因为它提供了纠正数据丢失错误的机会。此参数允许将恢复延迟指定的时间。例如，将此参数设置为 \u003ccode class=\"literal\"\u003e5min\u003c/code\u003e 时，只有当备库系统时间比主库报告的提交时间至少晚五分钟，备库才会重放各事务的提交。如果没有指定单位，则以毫秒计。默认值为零，不增加延迟。\n       \u003c/p\u003e\u003cp\u003e\n        服务器之间的复制延迟可能超过此参数的值，这种情况下不会增加延迟。注意，延迟根据主库写入的 WAL 时间戳与备库当前时间之差计算。网络延迟或级联复制配置导致的传输延迟，可能显著缩短实际等待时间。如果主库和备库的系统时钟不同步，恢复时可能比预期更早应用记录；但这通常不是主要问题，因为此参数的实用取值远大于服务器间常见的时间偏差。\n       \u003c/p\u003e\u003cp\u003e\n        延迟仅发生在事务提交的 WAL 记录上。其他记录会尽快重放；这不会造成问题，因为 MVCC 可见性规则确保在对应提交记录被应用之前，它们的效果不会可见。\n       \u003c/p\u003e\u003cp\u003e\n        恢复中的数据库达到一致状态后开始延迟，直到备库被提升或触发。此后，备库会结束恢复，不再等待。\n       \u003c/p\u003e\u003cp\u003e\n        WAL 记录必须保留在备库上，直到可以应用它们。因此，更长的延迟会导致更多 WAL 文件积压，增加备库 \u003ccode class=\"filename\"\u003epg_wal\u003c/code\u003e 目录所需的磁盘空间。\n       \u003c/p\u003e\u003cp\u003e\n        此参数旨在用于流复制部署；不过，只要指定了此参数，它就会在除崩溃恢复以外的所有情况下生效。使用此功能也会延迟 \u003ccode class=\"varname\"\u003ehot_standby_feedback\u003c/code\u003e，可能导致主库膨胀；同时使用两者时应谨慎。\n        \u003c/p\u003e\u003cdiv class=\"warning\"\u003e\u003ch3 class=\"title\"\u003e警告\u003c/h3\u003e\u003cp\u003e\n          当 \u003ccode class=\"varname\"\u003esynchronous_commit\u003c/code\u003e 设置为 \u003ccode class=\"literal\"\u003eremote_apply\u003c/code\u003e 时，同步复制会受到此设置影响；每个 \u003ccode class=\"literal\"\u003eCOMMIT\u003c/code\u003e 都必须等待提交被应用。\n         \u003c/p\u003e\u003c/div\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n        此参数只能在 \u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e 文件中或服务器命令行上设置。\n       \u003c/p\u003e","doc":{"anchor":"GUC-RECOVERY-MIN-APPLY-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"},"doc_html":"\u003cp\u003e\n        By default, a standby server restores WAL records from the\n        sending server as soon as possible. It may be useful to have a time-delayed\n        copy of the data, offering opportunities to correct data loss errors.\n        This parameter allows you to delay recovery by a specified amount\n        of time.  For example, if\n        you set this parameter to \u003ccode class=\"literal\"\u003e5min\u003c/code\u003e, the standby will\n        replay each transaction commit only when the system time on the standby\n        is at least five minutes past the commit time reported by the primary.\n        If this value is specified without units, it is taken as milliseconds.\n        The default is zero, adding no delay.\n       \u003c/p\u003e\u003cp\u003e\n        It is possible that the replication delay between servers exceeds the\n        value of this parameter, in which case no delay is added.\n        Note that the delay is calculated between the WAL time stamp as written\n        on primary and the current time on the standby. Delays in transfer\n        because of network lag or cascading replication configurations\n        may reduce the actual wait time significantly. If the system\n        clocks on primary and standby are not synchronized, this may lead to\n        recovery applying records earlier than expected; but that is not a\n        major issue because useful settings of this parameter are much larger\n        than typical time deviations between servers.\n       \u003c/p\u003e\u003cp\u003e\n        The delay occurs only on WAL records for transaction commits.\n        Other records are replayed as quickly as possible, which\n        is not a problem because MVCC visibility rules ensure their effects\n        are not visible until the corresponding commit record is applied.\n       \u003c/p\u003e\u003cp\u003e\n        The delay occurs once the database in recovery has reached a consistent\n        state, until the standby is promoted or triggered. After that the standby\n        will end recovery without further waiting.\n       \u003c/p\u003e\u003cp\u003e\n        WAL records must be kept on the standby until they are ready to be\n        applied. Therefore, longer delays will result in a greater accumulation\n        of WAL files, increasing disk space requirements for the standby's\n        \u003ccode class=\"filename\"\u003epg_wal\u003c/code\u003e directory.\n       \u003c/p\u003e\u003cp\u003e\n        This parameter is intended for use with streaming replication deployments;\n        however, if the parameter is specified it will be honored in all cases\n        except crash recovery.\n\n        \u003ccode class=\"varname\"\u003ehot_standby_feedback\u003c/code\u003e will be delayed by use of this feature\n        which could lead to bloat on the primary; use both together with care.\n\n        \u003c/p\u003e\u003cdiv class=\"warning\"\u003e\u003ch3 class=\"title\"\u003eWarning\u003c/h3\u003e\u003cp\u003e\n          Synchronous replication is affected by this setting when \u003ccode class=\"varname\"\u003esynchronous_commit\u003c/code\u003e\n          is set to \u003ccode class=\"literal\"\u003eremote_apply\u003c/code\u003e; every \u003ccode class=\"literal\"\u003eCOMMIT\u003c/code\u003e\n          will need to wait to be applied.\n         \u003c/p\u003e\u003c/div\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n        This parameter can only be set in the \u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e\n        file or on the server command line.\n       \u003c/p\u003e","doc_same_as":"","documentation_revision":{"inputs":[{"file":"runtime-config-replication.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","version":"18.7"},{"file":"runtime-config-replication.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"83907b5f469e979a7b9ec875b5e7bdaa2ef6b85596ca31b45174f68cd7398b18","version":"18.7"}],"release":"18.7","runtime_remeasured":false,"source_revision":"pgdoc:b9f0e7232f60f380d642ac9b99226606c254b552"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"2147483647","metadata_version":"18","min_val":"0","name":"recovery_min_apply_delay","short_desc":"Sets the minimum delay for applying changes during recovery.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-replication.html","sha256":"52bd5892f7e5511d05f46fc0c13a017de85307c674a9014948eb4ad480326c15"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":"ms","vartype":"integer","zh_from":"same-version-manual"},"ManualEvidence":{"doc":{"anchor":"GUC-RECOVERY-MIN-APPLY-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"c0b8bd86131ec62d4df97ce480d004aa7e3544477d053f0c2d4047b9edad5cc0","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"recovery_min_apply_delay","SourceDatabase":"center","Version":"18","Locale":"en","Title":"recovery_min_apply_delay","Summary":"By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to 5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the primary. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay. It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on primary and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on primary and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers. The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied. The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting. WAL records must be kept on the standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's pg_wal directory. This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases except crash recovery. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the primary; use both together with care. Warning Synchronous replication is affected by this setting when synchronous_commit is set to remote_apply; every COMMIT will need to wait to be applied. This parameter can only be set in the postgresql.conf file or on the server command line.","BodyHTML":"\u003cp\u003e\n        By default, a standby server restores WAL records from the\n        sending server as soon as possible. It may be useful to have a time-delayed\n        copy of the data, offering opportunities to correct data loss errors.\n        This parameter allows you to delay recovery by a specified amount\n        of time.  For example, if\n        you set this parameter to \u003ccode\u003e5min\u003c/code\u003e, the standby will\n        replay each transaction commit only when the system time on the standby\n        is at least five minutes past the commit time reported by the primary.\n        If this value is specified without units, it is taken as milliseconds.\n        The default is zero, adding no delay.\n       \u003c/p\u003e\u003cp\u003e\n        It is possible that the replication delay between servers exceeds the\n        value of this parameter, in which case no delay is added.\n        Note that the delay is calculated between the WAL time stamp as written\n        on primary and the current time on the standby. Delays in transfer\n        because of network lag or cascading replication configurations\n        may reduce the actual wait time significantly. If the system\n        clocks on primary and standby are not synchronized, this may lead to\n        recovery applying records earlier than expected; but that is not a\n        major issue because useful settings of this parameter are much larger\n        than typical time deviations between servers.\n       \u003c/p\u003e\u003cp\u003e\n        The delay occurs only on WAL records for transaction commits.\n        Other records are replayed as quickly as possible, which\n        is not a problem because MVCC visibility rules ensure their effects\n        are not visible until the corresponding commit record is applied.\n       \u003c/p\u003e\u003cp\u003e\n        The delay occurs once the database in recovery has reached a consistent\n        state, until the standby is promoted or triggered. After that the standby\n        will end recovery without further waiting.\n       \u003c/p\u003e\u003cp\u003e\n        WAL records must be kept on the standby until they are ready to be\n        applied. Therefore, longer delays will result in a greater accumulation\n        of WAL files, increasing disk space requirements for the standby\u0026#39;s\n        \u003ccode\u003epg_wal\u003c/code\u003e directory.\n       \u003c/p\u003e\u003cp\u003e\n        This parameter is intended for use with streaming replication deployments;\n        however, if the parameter is specified it will be honored in all cases\n        except crash recovery.\n\n        \u003ccode\u003ehot_standby_feedback\u003c/code\u003e will be delayed by use of this feature\n        which could lead to bloat on the primary; use both together with care.\n\n        \u003c/p\u003e\u003cdiv\u003e\u003ch3\u003eWarning\u003c/h3\u003e\u003cp\u003e\n          Synchronous replication is affected by this setting when \u003ccode\u003esynchronous_commit\u003c/code\u003e\n          is set to \u003ccode\u003eremote_apply\u003c/code\u003e; every \u003ccode\u003eCOMMIT\u003c/code\u003e\n          will need to wait to be applied.\n         \u003c/p\u003e\u003c/div\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n        This parameter can only be set in the \u003ccode\u003epostgresql.conf\u003c/code\u003e\n        file or on the server command line.\n       \u003c/p\u003e","SourceRevision":"wiki-repair-20261023:559663fa4b3be19d7d8daa12d62f372e9e265c036cf87e077fa945b6bffd2a17","ContentHash":"00711f439f8209e82318fb6413d6e86d357e32bee350fab90993fe5664905157","Payload":{"description":"By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to 5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the primary. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay. It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on primary and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on primary and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers. The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied. The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting. WAL records must be kept on the standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's pg_wal directory. This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases except crash recovery. hot_standby_feedback will be delayed by use of this feature which could lead to bloat on the primary; use both together with care. Warning Synchronous replication is affected by this setting when synchronous_commit is set to remote_apply; every COMMIT will need to wait to be applied. This parameter can only be set in the postgresql.conf file or on the server command line."}},"RequestedLocale":"en","Fallback":false,"Versions":["12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}