PostgreSQL · Write-Ahead Log

Replication Slots: Lifecycle & WAL Recycling

Two chronological walkthroughs over one shared WAL stream. Watch the slot data structure mutate field-by-field, the physical disk fill and free, and see who decides each cleanup — the DBA (explicit) or the Postgres server (automatic, at checkpoint).

Physical Disk · pg_wal/ one shared WAL stream · segments recycle left → new writes append right

write head (current LSN) live WAL (retained) pinned by a slot's restart_lsn recycled / freed

WAL held on disk

Slots · pg_replication_slots

Narration

wal_status — what each state means for the slot & the disk

Status	What it means	WAL on disk	Can the consumer resume?
reserved	Normal. Slot is keeping up (within `wal_keep_size`).	Retained & safe.	Yes.
extended	Slot lags past `wal_keep_size` but still under `max_slot_wal_keep_size`.	Extra WAL held. `safe_wal_size` shrinking.	Yes — warning only.
unreserved	Past the cap; this WAL is about to be removed on the next checkpoint.	`safe_wal_size ≈ 0`. Last chance.	Yes, if it reconnects immediately.
lost	Postgres removed the WAL and invalidated the slot to protect the disk.	Freed. `restart_lsn = NULL`.	No — full resync required.

wal_level = logical · one WAL per instance · restart_lsn = oldest byte a slot still needs