"Postgres WAIT FOR LSN: Read-Your-Writes on Replicas, No Polling"
Postgres WAIT FOR LSN in PostgreSQL 19 beta — get read-your-writes consistency on async replicas without polling loops, with TIMEOUT, NO_THROW, and the session pattern.
Postgres wait for lsn is PostgreSQL 19's answer to the most annoying bug in read-replica architectures: a user writes something, your app reads from the replica a millisecond later, and the write isn't there yet. The old fix was a polling loop — hammer pg_last_wal_replay_lsn() until the replica catches up, or just sleep() and retry and hope. PG19 replaces all of that with a single statement: WAIT FOR LSN , run on the replica before your read, which blocks until the replica has replayed your write's WAL position. One benchmark measured 0 stale reads across 5,000 writes. It's in beta4 — so this post carries the beta flag, and you should verify the final syntax against the PG19 release notes at GA before building on it. BETA FLAG: PostgreSQL 19 is still in beta (beta4 shipped 2026-09-24; RC1 scheduled 2026-10-15; GA scheduled 2026-10-29). WAIT FOR is confirmed shipping as of beta4 — and beta4 shipped several fixes for it, including a deadlock — but its final form should be verified against the PG19 release notes at GA before you ship anything built on it. Do not run beta in production. Last updated: October 4, 2026 What you'll learn Why read-after-write against an async replica is broken by default The old pattern: pg_last_wal_replay_lsn() polling (and why it stinks) Capturing the write's LSN on the primary with pg_current_wal_insert_lsn() The WAIT FOR LSN syntax: modes, TIMEOUT , NO_THROW The session/cookie pattern for wiring it into a real app How it differs from synchronous_commit = remote_apply The Problem: Read Your Writes on a Replica The setup is everywhere: writes go to the primary, reads fan out to replicas. Replication is asynchronous, so there's a lag window — small, but real. The user-visible failure: User posts a comment →…