{"Entry":{"collection":"guc","key":"synchronous_commit","name":"synchronous_commit","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Write-Ahead Log / Settings","category_zh":"","changed_in":["9.1","9.2","9.6"],"changes":[{"documentation_changed":false,"fields":{},"from":"8.2","status":"added","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"8.4","status":"changed","to":"9.0"},{"documentation_changed":true,"fields":{"enumvals":{"from":null,"to":["local","on","off"]},"short_desc":{"from":"Sets immediate fsync at commit.","to":"Sets the current transaction's synchronization level."},"vartype":{"from":"bool","to":"enum"}},"from":"9.0","status":"changed","to":"9.1"},{"documentation_changed":true,"fields":{"enumvals":{"from":["local","on","off"],"to":["local","remote_write","on","off"]}},"from":"9.1","status":"changed","to":"9.2"},{"documentation_changed":true,"fields":{},"from":"9.4","status":"changed","to":"9.5"},{"documentation_changed":true,"fields":{"enumvals":{"from":["local","remote_write","on","off"],"to":["local","remote_write","remote_apply","on","off"]}},"from":"9.5","status":"changed","to":"9.6"},{"documentation_changed":true,"fields":{},"from":"9.6","status":"changed","to":"10"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"13","status":"changed","to":"14"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"}],"content_hash":"e5b80835169b286cdfa2949dfa8f5e6c9ed99da0dfdce6559e0871d9ab9a59ab","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"on"}],"editorial":{"advice":{"olap":"For a reproducible bulk load, transaction-local off can improve throughput if losing the final unflushed portion is acceptable and the load can be rerun. Keep catalog changes, handoff markers, and externally visible completion records synchronous.","oltp":"Keep on as the general default. Use off only for explicitly replaceable transactions, and use remote_apply only when post-commit reads on a synchronous standby require causal visibility; include network round-trip and standby health in the latency budget.","small":"Retain on. Small systems rarely gain enough from a global durability downgrade to justify the operational ambiguity; tune individual noncritical jobs instead."},"mechanism":["All modes except off wait for the transaction's WAL to be flushed locally. With off, success can be returned before local durable flush; a crash can lose recent acknowledged transactions, but recovery remains transactionally consistent and does not introduce the corruption risk associated with fsync = off.","When synchronous_standby_names selects synchronous standbys, remote_write waits for receipt and an operating-system write on a standby, on waits for a durable standby flush, and remote_apply waits for replay and query visibility. local waits only for local durable flush. Without a selected synchronous standby, the remote modes add no remote guarantee.","The effective mode is the value in force when a transaction commits. Applications can use SET LOCAL for one transaction, allowing critical and replaceable work to use different durability policies on the same server."],"pitfalls":["Equating synchronous_commit = off with fsync = off; the former risks recent data loss, not structural corruption.","Expecting remote_write, on, or remote_apply to wait remotely when no synchronous standby is selected.","Using remote_write while assuming the standby is durable across an operating-system crash.","Allowing an unavailable synchronous standby to stall commits without an HA response plan.","Leaking a session-level SET through a connection pool instead of using SET LOCAL or reset discipline."],"references":[{"title":"PostgreSQL 19 Beta 4: synchronous_commit","url":"https://www.postgresql.org/docs/19/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT"},{"title":"PostgreSQL 18: Asynchronous Commit","url":"https://www.postgresql.org/docs/18/wal-async-commit.html"},{"title":"PostgreSQL 18: Synchronous Replication","url":"https://www.postgresql.org/docs/18/warm-standby.html#SYNCHRONOUS-REPLICATION"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["synchronous_standby_names","fsync","wal_writer_delay","wal_sync_method","commit_delay","wal_level"],"summary":"synchronous_commit — Sets the current transaction's synchronization level. Observed in PG9.0–19 Beta 4; its last measured boot default is on in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"8.3","group":"Write-Ahead Log","group_slug":"wal","imported_at":"2026-09-27T17:57:32.099005+08:00","intro_commit":{},"key":"synchronous_commit","last_version":"20","max_val":"","min_val":"","name":"synchronous_commit","position":399,"present_in":["8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"Specifies how much WAL processing must complete before the database server returns a “success” indication to the client.","short_desc_zh":"","source_rev":"english-manuals:2239aa7d2084ff1bd7b2a3dd4916e6f8fecaf8459c043c836c5485a44102f838","unit":"","vartype":"enum"}},"Definition":{"Collection":"guc","Key":"synchronous_commit","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"synchronous_commit","SourceRevision":"english-manuals:2239aa7d2084ff1bd7b2a3dd4916e6f8fecaf8459c043c836c5485a44102f838","Facts":{"boot_val":"on","category":"Write-Ahead Log / Settings","context":"user","description":"Specifies how much WAL processing must complete before the database server returns a “success” indication to the client. Valid values are remote_apply, on (the default), remote_write, local, and off. If synchronous_standby_names is empty, the only meaningful settings are on and off; remote_apply, remote_write and local all provide the same local synchronization level as on. The local behavior of all non-off modes is to wait for local flush of WAL to disk. In off mode, there is no waiting, so there can be a delay between when success is reported to the client and when the transaction is later guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) Unlike fsync, setting this parameter to off does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning synchronous_commit off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see Section 28.4. If synchronous_standby_names is non-empty, synchronous_commit also controls whether transaction commits will wait for their WAL records to be processed on the standby server(s). When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s), and also written to durable storage on the standbys. This will cause much larger commit delays than previous settings since it waits for WAL replay. When set to on, commits wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to durable storage. This ensures the transaction will not be lost unless both the primary and all synchronous standbys suffer corruption of their database storage. When set to remote_write, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it to their file systems. This setting ensures data preservation if a standby instance of PostgreSQL crashes, but not if the standby suffers an operating-system-level crash because the data has not necessarily reached durable storage on the standby. The setting local causes commits to wait for local flush to disk, but not for replication. This is usually not desirable when synchronous replication is in use, but is provided for completeness. This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction. Table 19.1 summarizes the capabilities of the synchronous_commit settings. Table 19.1. synchronous_commit Modes synchronous_commit setting local durable commit standby durable commit after PG crash standby durable commit after OS crash standby query consistency remote_apply • • • • on • • • remote_write • • local • off","doc":{"anchor":"GUC-SYNCHRONOUS-COMMIT","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"},"documented":true,"enumvals":["local","remote_write","remote_apply","on","off"],"extra_desc":null,"lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"synchronous_commit","short_desc":"Sets the current transaction's synchronization level.","source":"pg-settings-source-snapshot","unit":null,"vartype":"enum"},"ManualEvidence":{"doc":{"anchor":"GUC-SYNCHRONOUS-COMMIT","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"synchronous_commit","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"synchronous_commit","Summary":"","BodyHTML":"\u003cp\u003e指定数据库服务器向客户端返回\u003cspan\u003e“\u003cspan\u003e成功\u003c/span\u003e”\u003c/span\u003e指示之前，必须完成多少 WAL 处理。有效值为\u003ccode\u003eremote_apply\u003c/code\u003e、\u003ccode\u003eon\u003c/code\u003e（默认值）、\u003ccode\u003eremote_write\u003c/code\u003e、\u003ccode\u003elocal\u003c/code\u003e和\u003ccode\u003eoff\u003c/code\u003e。\u003c/p\u003e\u003cp\u003e如果\u003ccode\u003esynchronous_standby_names\u003c/code\u003e为空，只有\u003ccode\u003eon\u003c/code\u003e和\u003ccode\u003eoff\u003c/code\u003e两种设置有意义；\u003ccode\u003eremote_apply\u003c/code\u003e、\u003ccode\u003eremote_write\u003c/code\u003e和\u003ccode\u003elocal\u003c/code\u003e提供的本地同步级别都与\u003ccode\u003eon\u003c/code\u003e相同。所有非\u003ccode\u003eoff\u003c/code\u003e模式在本地都会等待 WAL 刷写到磁盘。在\u003ccode\u003eoff\u003c/code\u003e模式下则无需等待，因此，向客户端报告成功后，可能还要经过一段时间，才能保证事务不会因服务器崩溃而丢失。（最大延迟为\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-WAL-WRITER-DELAY\" rel=\"nofollow\"\u003ewal_writer_delay\u003c/a\u003e的三倍。）与\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-FSYNC\" rel=\"nofollow\"\u003efsync\u003c/a\u003e不同，将此参数设为\u003ccode\u003eoff\u003c/code\u003e不会带来数据库不一致的风险：操作系统或数据库崩溃可能会使一些最近报告已提交的事务丢失，但数据库状态会与这些事务已正常中止时完全相同。因此，当性能比完全确保事务持久性更重要时，关闭\u003ccode\u003esynchronous_commit\u003c/code\u003e可以是一种有用的替代方案。更多讨论见\u003ca href=\"/docs/18/wal-async-commit.html\" rel=\"nofollow\"\u003e第 28.4 节\u003c/a\u003e。\u003c/p\u003e\u003cp\u003e如果\u003ca href=\"/docs/18/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES\" rel=\"nofollow\"\u003esynchronous_standby_names\u003c/a\u003e非空，\u003ccode\u003esynchronous_commit\u003c/code\u003e还控制事务提交是否等待备库处理其 WAL 记录。\u003c/p\u003e\u003cp\u003e设为\u003ccode\u003eremote_apply\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到并应用该事务的提交记录，使其对备库上的查询可见，并且已将其写入备库的持久存储。由于需要等待 WAL 重放，这会比之前的设置产生大得多的提交延迟。设为\u003ccode\u003eon\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到持久存储。这能保证事务不会丢失，除非主库和所有同步备库的数据库存储都损坏。设为\u003ccode\u003eremote_write\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入各自的文件系统。此设置能保证备库上的\u003cspan\u003ePostgreSQL\u003c/span\u003e实例崩溃时数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失，因为数据未必已写入备库的持久存储。设为\u003ccode\u003elocal\u003c/code\u003e时，提交会等待本地刷盘，但不等待复制。使用同步复制时通常不希望采用这种设置，提供它是为了使选项完整。\u003c/p\u003e\u003cp\u003e此参数可以随时更改；每个事务的行为由提交时生效的设置决定。因此，让一些事务同步提交、另一些事务异步提交是可行且有用的。例如，当默认设置要求同步提交时，可以在一个包含多条语句的事务中执行\u003ccode\u003eSET LOCAL synchronous_commit TO OFF\u003c/code\u003e，使该事务异步提交。\u003c/p\u003e\u003cp\u003e\u003ca href=\"/docs/18/runtime-config-wal.html#SYNCHRONOUS-COMMIT-MATRIX\" rel=\"nofollow\"\u003e表 19.1\u003c/a\u003e汇总了\u003ccode\u003esynchronous_commit\u003c/code\u003e各种设置具备的能力。\u003c/p\u003e\u003cdiv\u003e\u003cp\u003e\u003cstrong\u003e表 19.1. synchronous_commit 模式\u003c/strong\u003e\u003c/p\u003e\u003cdiv\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003esynchronous_commit 设置\u003c/th\u003e\u003cth\u003e本地提交持久性\u003c/th\u003e\u003cth\u003ePG 崩溃后备库提交持久性\u003c/th\u003e\u003cth\u003eOS 崩溃后备库提交持久性\u003c/th\u003e\u003cth\u003e备库查询一致性\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eremote_apply\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eon\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eremote_write\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003elocal\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eoff\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003c/div\u003e\u003c/div\u003e\u003cbr\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"1b2fbe863141257285f2a73c886e57b69c0850df84c903ae05984978aa8a5c0f","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e指定数据库服务器向客户端返回\u003cspan class=\"quote\"\u003e“\u003cspan class=\"quote\"\u003e成功\u003c/span\u003e”\u003c/span\u003e指示之前，必须完成多少 WAL 处理。有效值为\u003ccode class=\"literal\"\u003eremote_apply\u003c/code\u003e、\u003ccode class=\"literal\"\u003eon\u003c/code\u003e（默认值）、\u003ccode class=\"literal\"\u003eremote_write\u003c/code\u003e、\u003ccode class=\"literal\"\u003elocal\u003c/code\u003e和\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e。\u003c/p\u003e\u003cp\u003e如果\u003ccode class=\"varname\"\u003esynchronous_standby_names\u003c/code\u003e为空，只有\u003ccode class=\"literal\"\u003eon\u003c/code\u003e和\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e两种设置有意义；\u003ccode class=\"literal\"\u003eremote_apply\u003c/code\u003e、\u003ccode class=\"literal\"\u003eremote_write\u003c/code\u003e和\u003ccode class=\"literal\"\u003elocal\u003c/code\u003e提供的本地同步级别都与\u003ccode class=\"literal\"\u003eon\u003c/code\u003e相同。所有非\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e模式在本地都会等待 WAL 刷写到磁盘。在\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e模式下则无需等待，因此，向客户端报告成功后，可能还要经过一段时间，才能保证事务不会因服务器崩溃而丢失。（最大延迟为\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-WAL-WRITER-DELAY\"\u003ewal_writer_delay\u003c/a\u003e的三倍。）与\u003ca href=\"/docs/18/runtime-config-wal.html#GUC-FSYNC\"\u003efsync\u003c/a\u003e不同，将此参数设为\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e不会带来数据库不一致的风险：操作系统或数据库崩溃可能会使一些最近报告已提交的事务丢失，但数据库状态会与这些事务已正常中止时完全相同。因此，当性能比完全确保事务持久性更重要时，关闭\u003ccode class=\"varname\"\u003esynchronous_commit\u003c/code\u003e可以是一种有用的替代方案。更多讨论见\u003ca href=\"/docs/18/wal-async-commit.html\" title=\"28.4. 异步提交\"\u003e第 28.4 节\u003c/a\u003e。\u003c/p\u003e\u003cp\u003e如果\u003ca href=\"/docs/18/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES\"\u003esynchronous_standby_names\u003c/a\u003e非空，\u003ccode class=\"varname\"\u003esynchronous_commit\u003c/code\u003e还控制事务提交是否等待备库处理其 WAL 记录。\u003c/p\u003e\u003cp\u003e设为\u003ccode class=\"literal\"\u003eremote_apply\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到并应用该事务的提交记录，使其对备库上的查询可见，并且已将其写入备库的持久存储。由于需要等待 WAL 重放，这会比之前的设置产生大得多的提交延迟。设为\u003ccode class=\"literal\"\u003eon\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到持久存储。这能保证事务不会丢失，除非主库和所有同步备库的数据库存储都损坏。设为\u003ccode class=\"literal\"\u003eremote_write\u003c/code\u003e时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入各自的文件系统。此设置能保证备库上的\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e实例崩溃时数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失，因为数据未必已写入备库的持久存储。设为\u003ccode class=\"literal\"\u003elocal\u003c/code\u003e时，提交会等待本地刷盘，但不等待复制。使用同步复制时通常不希望采用这种设置，提供它是为了使选项完整。\u003c/p\u003e\u003cp\u003e此参数可以随时更改；每个事务的行为由提交时生效的设置决定。因此，让一些事务同步提交、另一些事务异步提交是可行且有用的。例如，当默认设置要求同步提交时，可以在一个包含多条语句的事务中执行\u003ccode class=\"command\"\u003eSET LOCAL synchronous_commit TO OFF\u003c/code\u003e，使该事务异步提交。\u003c/p\u003e\u003cp\u003e\u003ca href=\"/docs/18/runtime-config-wal.html#SYNCHRONOUS-COMMIT-MATRIX\" title=\"表 19.1. synchronous_commit 模式\"\u003e表 19.1\u003c/a\u003e汇总了\u003ccode class=\"varname\"\u003esynchronous_commit\u003c/code\u003e各种设置具备的能力。\u003c/p\u003e\u003cdiv class=\"table\"\u003e\u003cp class=\"title\"\u003e\u003cstrong\u003e表 19.1. synchronous_commit 模式\u003c/strong\u003e\u003c/p\u003e\u003cdiv class=\"table-contents\"\u003e\u003ctable class=\"table\"\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003esynchronous_commit 设置\u003c/th\u003e\u003cth\u003e本地提交持久性\u003c/th\u003e\u003cth\u003ePG 崩溃后备库提交持久性\u003c/th\u003e\u003cth\u003eOS 崩溃后备库提交持久性\u003c/th\u003e\u003cth\u003e备库查询一致性\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eremote_apply\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eon\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eremote_write\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003elocal\u003c/td\u003e\u003ctd\u003e•\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eoff\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003ctd\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003c/div\u003e\u003c/div\u003e\u003cbr\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}