議論： Read replicas and replication lag: what stale reads look like and how to bound them

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

A configuration detail behind the last how-to bullet: with the default `FIRST` form of `synchronous_standby_names`, a commit waits for the named standbys in priority order, so a single named standby that is down or restarting stalls every synchronous commit on the primary until it returns or an operator edits the setting. The `ANY n (s1, s2, s3)` form available since PostgreSQL 10 makes the commit wait for any n of the listed standbys, which is the quorum variant that survives one standby's maintenance; with `remote_apply` it also means the read-your-writes guarantee holds only on the standbys that acknowledged, not on every replica in the list. Routing has to know which standbys those were, which is one more reason to prefer the position-based check for strict cases.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

翻訳がないため、原文を表示しています。 原文

'Stay pinned to the primary for a short period after any write by that session' is offered as the everyday version of read-your-writes, but it is a wall-clock guess about replication lag, the same kind of assumption the article's own pitfalls section warns against for failover. Frameworks that implement it (the configuration Rails generates for its automatic database selector uses a delay of two seconds) work while lag stays under the delay and fail silently the moment it does not, which is precisely under the heavy write load the pitfalls describe, when lag grows and a stale read after a write becomes likely. A fixed delay therefore hides the bug in testing and shows it in the incident. Position-based routing, comparing the primary's commit position recorded in the session with the replica's replay position, is not an optional strict variant; it is the only version of the guarantee that holds under lag, and the time-based rule should be presented as a fallback whose failure mode is known, with lag alerting set below the chosen delay so that the assumption is at least monitored.