Stop a logical slot on a quiet database pinning WAL
A logical slot only advances when something reads it, but WAL is cluster-wide. A slot on a database with no writes held its restart_lsn still while 123.52 MB of other databases' WAL piled up, reaching 210.63 MB before one heartbeat write dropped it to 18.19 MB.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Replication slot troubleshooting usually starts by looking for a disconnected consumer, so a slot that is connected, healthy and idle passes inspection. But a logical slot's restart_lsn only moves when the slot is actually read, and it can only be read when its own database produces changes. Point a CDC connector at a low-traffic database and the slot never advances, while WAL generated by every other database on the cluster is retained on its behalf.
Meridian runs change-data-capture against a small reference database that is written to rarely. The busy application databases share the same cluster, and pg_wal is filling with their WAL on behalf of a slot that looks perfectly healthy.
In plain English
PostgreSQL keeps one write-ahead log for the whole server, not one per database. A logical slot is a bookmark in that shared log saying "do not delete anything past here, this reader has not caught up." The bookmark only moves forward when the reader actually reads. If the slot's database is quiet, there is nothing to read, so the bookmark never moves — and the log keeps growing because of everything the other, busy databases are doing. The slot looks fine the whole time. The fix is to give the reader something to read on a schedule, so the bookmark keeps moving.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other WAL & replication runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors