max_slot_wal_keep_size
Fact — official short description: “Sets the maximum WAL size that can be reserved by replication slots.”
Identity
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG13 |
| Present in | PG13–19 Beta 3 |
| Removed in | No |
| Introduction commit | c6550776394e — Allow users to limit storage reserved by replication slots |
| Commit date | 2020-04-07 |
| Discussion | thread 1 |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG13–19 Beta 3 | -1 |
MB |
-1 MB |
How it works
At checkpoint time PostgreSQL compares a slot’s restart_lsn with the current WAL position. With the default -1 there is no parameter-imposed maximum; a stalled consumer can therefore retain enough WAL to fill pg_wal.
With a finite limit, required segments can be released when a slot falls too far behind. The slot can move through unreserved to lost status, and its consumer may need a new base backup or logical resynchronization. The cap protects server storage by sacrificing the guarantee that an indefinitely lagging slot remains usable.
Enforcement is checkpoint-based, so it is neither instantaneous nor an exact byte ceiling. pg_replication_slots exposes restart_lsn, wal_status, invalidation_reason, and safe_wal_size; these are the operational signals needed before the slot reaches the limit.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| OLTP | Set a finite limit within the pg_wal emergency budget and derive it from peak WAL generation times the maximum supported repair window. Alert while safe_wal_size is still positive, and document the resynchronization path for every consumer. |
| OLAP | Allow for expected bulk-WAL bursts, but do not make the cap effectively unlimited. Schedule consumers and batch jobs together, verify archive availability, and pause or repair a lagging consumer before it consumes the disk budget. |
| Small nodes | Use a stricter finite cap and a short repair objective. On a small volume, preserving the primary is usually more important than keeping a stale replica or CDC slot resumable forever. |
Pigsty
Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.
| Template | Effective value | Versus upstream boot | Source expression |
|---|---|---|---|
| OLTP | 30GB |
different | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| OLAP | 30GB |
different | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| CRIT | 30GB |
different | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| TINY | 30GB |
different | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG13–19 Beta 3 = 30GB (dcs); OLAP: PG13–19 Beta 3 = 30GB (dcs); CRIT: PG13–19 Beta 3 = 30GB (dcs); TINY: PG13–19 Beta 3 = 30GB (dcs). Advice, pending human review — confirm the operational intent against the current Pigsty templates and supported PostgreSQL versions before publication.
Common pitfalls
- Leaving -1 and assuming a stalled slot cannot fill the disk.
- Treating the finite value as an instantaneous hard ceiling despite checkpoint-based enforcement.
- Setting it too low and invalidating a healthy consumer during a planned bulk load.
- Assuming a consumer can always resume after its required WAL has been removed.
- Confusing this per-slot retention cap with the wal_keep_size retention floor.
Related parameters
max_replication_slots · wal_keep_size · max_wal_size · idle_replication_slot_timeout · checkpoint_timeout · archive_mode
References
- PostgreSQL 19 Beta 3 — max_slot_wal_keep_size
- PostgreSQL 18: Replication Slots
- PostgreSQL 18: pg_replication_slots
- PostgreSQL 19 release notes
- Machine-readable GUC export