Synchronous replication makes configured standbys confirm replicated changes before the committing transaction completes. It can reduce stale-read risk and help prevent distributed serialization anomalies, but every commit pays the network round-trip cost. section 5.6
The correctness–latency tradeoff
A report running on standby beta reads rows while users modify and vacuum them on primary alpha. The report can fail with “canceling statement due to conflict with recovery” when recovery removes row versions it still needs. Synchronous replication may prevent this class of stale-read or read-write conflict, but the resulting latency can bottleneck database performance. Read replicas remain useful for workload offloading, but not inside an application atomic operation spread across nodes. section 5.6
SELECT sum(balance) FROM test.accounts UNION SELECT avg(balance) FROM test.accounts; ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed.
Inspect the concrete recovery-conflict error produced when a long-running standby query needs row versions removed by primary-side cleanup. section 5.6
