WAIT FOR the Feature for Almost 10 Years
October 20–23
Asynchronous replication always leaves a window: you commit on the primary, immediately query a replica, and your own write isn't there yet. The fix sounds trivial — let the client wait until the replica has replayed up to a given LSN before reading. WAIT FOR LSN finally ships in PostgreSQL 19, and getting it there took the better part of a decade. In this talk I'll explain why such a "simple" feature was anything but. The central obstacle is subtle: on a standby, you cannot wait while holding a snapshot. Recovery advances visibility by replaying WAL, but an open snapshot pins an old view of the database and can block that replay — so a backend waiting inside a transaction for WAL to advance can end up waiting on itself. A textbook self-deadlock, hiding inside a one-line feature. I'll walk through the design attempts this constraint killed off — implementing it as a function, folding it into an existing statement, making it a procedure — and why each ran aground on snapshot semantics, SQL grammar, or what should even happen mid-transaction. The answer the community converged on was a brand-new top-level SQL statement that holds no snapshot at all, with all the grammar and infrastructure cost that implies. Beyond the post-mortem, this is a candid story of how features actually land in PostgreSQL: the reviews, redesigns, and reverts required to push one good idea through a community that refuses to compromise on correctness. If you've ever wondered why an "obvious" feature takes ten years, here's your answer.
