DATABASES Signal 329
What is WAL backpressure, and why does ClickHouse Managed Postgres need it?
↗
ClickHouse Managed Postgres adds WAL-aware backpressure that slows client writes when the write-ahead log archiver falls behind, protecting disk space and avoiding a panic.
When the archiver cannot keep up, unfinished WAL segments accumulate and can fill the disk, causing the Postgres instance to panic and go down. By throttling only the write path, the service lets the archiver catch up while keeping reads and recovery processes running.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The system monitors pending WAL segments periodically and reduces the write bandwidth of client backends in proportion to the backlog size.
Write throttling is applied through a split cgroup so that the archiver, checkpointer and related processes remain unthrottled and can drain the WAL queue at full speed.
When the backlog drops below the trigger level, the throttle is lifted automatically, restoring normal write performance without manual intervention.
THE READ
What elseif makes of it.
All changes to Postgres are first written to the write-ahead log before they reach tables. In a managed setup the service uploads each completed WAL segment to object storage so that point-in-time recovery remains possible. If the upload lags, the service cannot delete the segment and the log begins to accumulate on disk. A full WAL disk triggers a panic that stops the instance.
To prevent that outcome the service watches the number of pending WAL segments on a regular interval. When the count rises, it lowers the write bandwidth available to client connections by adjusting the cgroup I/O controller. The reduction is stronger as the backlog grows, giving the archiver more time to catch up.
The bandwidth limit is applied only to the throttled group that holds the client backends. The archiver, checkpointer, wal writer and related processes stay in an immune group and continue to run at full speed. As a result WAL generation slows while the archiver drains the backlog, keeping disk usage well below the panic point.
Once the pending segment count falls below the trigger level, the throttle is lifted on the next check and write performance returns to normal. The mechanism works entirely on the data plane, so it remains effective even if the control plane is unreachable or the object store is temporarily slow.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER