The directory holding a database's write-ahead log segments keeps growing until the disk is nearly full, even though the database's data size is stable. What causes log segments to accumulate, and how do you reason about it?

## How the log is stored The write-ahead log is not one endless file. It is a sequence of fixed-size segment files written in order. Once the engine is certain a segment is no longer needed, the file is deleted or (more often) renamed and reused for future writes, so steady-state log space is roughly constant. \"No longer needed\" is the whole question. A segment is retained while any of several consumers still requires the bytes in it. ## The consumers that pin log **Crash recovery.** Redo must start from the last checkpoint, so every segment from that point forward must exist. If checkpoints are not completing — because the interval or size threshold is huge, because the checkpointer is starved by I/O, or because it is blocked — the required start position stops advancing and the log piles up. Conversely, a long checkpoint interval is a deliberate tradeoff: less write amplification, more log retained, longer recovery. **Open transactions.** In engines that keep undo information in the same log, a transaction open for hours pins everything from its first change onward, because rollback might still need it. Even in engines with separate undo storage, an old transaction pins that structure instead and blocks reclamation there. \"Idle in transaction\" sessions — an application that began a transaction and then went to sleep, often through a connection pool — are the classic cause. **Replication consumers.** A physical or logical replica reports how far it has received and applied. The primary keeps log until the consumer confirms. Where the retention is expressed as a durable, named subscription (a slot), retention is unbounded by design: if that replica dies and nobody removes the slot, the primary retains log forever until the disk fills. This is the single most common cause of a log disk filling in a replicated deployment. Where retention is instead expressed as \"keep at most N segments\", you get the opposite failure mode: the replica falls too far behind, the segment it needs is gone, and it must be rebuilt. **Archiving / continuous backup.** If the engine is configured to ship each segment to archival storage before recycling it, a broken destination (bad credentials, full bucket, wrong path, hung command) pauses recycling entirely while writes continue. Retention grows at exactly the write rate. **Backups in progress.** A base backup pins the log from its start position so the backup can be made consistent. A backup that hangs for a day pins a day of log. ## Diagnosing it The portable method has three steps. 1. **Find the oldest required log position.** Every engine exposes this: the checkpoint's redo start, the oldest slot/consumer position, the oldest active transaction's start position, the last archived segment. 2. **Attribute it.** Whichever of those is furthest behind is the culprit; the distance from the current write position tells you how much log it is pinning. 3. **Fix the owner, not the symptom.** Reconnect or drop the abandoned replica/slot; kill or fix the ancient open transaction; repair the archive destination; let the backup finish or abort it. Deleting segment files by hand is destructive — it can make the database unrecoverable and break every consumer at once. Emergency space: if the disk is truly about to fill, buying time usually means removing the pinning consumer (dropping a dead slot is safe and instant) or adding space, not deleting log. ## Why it is urgent When the log device fills, the engine cannot write log records, and since no change may proceed without logging, writes stop. Many engines shut down or enter a read-only-ish panic state. So log growth is a countdown to an outage, and it is usually silent until the last few percent — which is why the right monitoring is \"log retention size and oldest required position\", alerted on trend, not just \"disk free\". ## Prevention Monitor retained log volume and the lag of every consumer in log bytes. Cap or alert on any durable retention mechanism (slot lag limits, maximum retention size). Alert on transactions open longer than a few minutes, and set server-side timeouts for idle-in-transaction sessions. Monitor archiving success as a first-class signal. Size the log filesystem for the worst realistic burst — a bulk load or index build can generate far more log per hour than the steady-state workload. ## Interview framing \"Segments are recycled when nothing needs them. Growth means something needs them: checkpoint, old transaction, lagging or abandoned replication consumer, failing archiver, or a running backup. Find the oldest required position, find its owner, fix that.\"