https://www.postgresscripts.com/tags/standby/Recent content in Standby on Postgres ScriptsHugo -- gohugo.ioenPostgresScripts.comFri, 22 May 2026 00:00:00 +0000https://www.postgresscripts.com/post/monitor-postgresql-replication-lag-with-pg-stat-replication/Fri, 22 May 2026 00:00:00 +0000https://www.postgresscripts.com/post/monitor-postgresql-replication-lag-with-pg-stat-replication/ <h2 id="monitor-postgresql-replication-lag-with-pg_stat_replication">Monitor PostgreSQL Replication Lag with pg_stat_replication</h2> <p>A standby lagging more than a few seconds is rarely a transient hiccup — it is a query backlog on the standby, a network ceiling between the nodes, a misconfigured <code>hot_standby_feedback</code>, or a single-threaded apply storm. <code>pg_stat_replication</code> joined to <code>pg_wal_lsn_diff()</code> exposes each replica's byte lag and time lag in one row, on the primary, no SSH required.</p> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1012089347386563" crossorigin="anonymous"></script> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-1012089347386563" data-ad-slot="7945792173" data-ad-format="auto" data-full-width-responsive="true"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> <h2 id="purpose-and-overview">Purpose and Overview</h2> <p>PostgreSQL streaming replication is asynchronous by default. The primary commits a transaction, writes the WAL record locally, the WAL sender forwards it to the standby, the standby writes it to its own WAL, flushes the WAL to disk, and finally replays it into the data files. Each stage runs on a separate thread of execution, and each stage has its own latency. Under load they diverge: write may be near-instant, flush a few milliseconds, and replay seconds or minutes behind on a busy standby.</p>