Question: Write-ahead log
Can I delete files from pg_wal?
Answered in the first paragraph. Last updated .
No. Every file in that directory is either required to bring the cluster back after a crash or about to be recycled by the server itself, and there is no way to tell those apart from names, sizes or timestamps. Removing the wrong one converts a full filesystem, which is an inconvenience with a known fix, into a cluster that will not start, which may end at a restore from backup.
What happens if you do it anyway
The server comes down, or is already down, and on the next start recovery looks for the record that continues the sequence. It is missing, so startup fails and keeps failing. There is a tool that rewrites the control information to make the server start regardless, and it works by discarding whatever those records contained, which means discarding committed transactions and accepting that the data files may now disagree with each other. Its own documentation treats it as a last resort and so should you. After using it, the only defensible next step is a dump, a rebuild and a careful comparison.
Meanwhile the ordinary version of this incident, the disk filling because something is holding segments, is entirely recoverable without touching a single file. Why pg_wal fills up has the four causes and the order to eliminate them in.
Getting space without touching the directory
Take it from somewhere else first. Old server logs, temporary files left by a crashed session, a stale base backup on the same volume, and the operating system’s own package cache are all fair game and none of them are load-bearing. Many teams keep a deliberately useless file of a few gigabytes on that filesystem for exactly this moment; deleting it buys the time to fix the real cause.
Then remove the cause rather than the symptom. That is a failing archive command, an abandoned slot, a retention setting inherited from another cluster, or checkpoints that cannot keep pace, and each has a fix that releases segments the supported way.
There is a supported cleanup tool, and its subject is the archive directory, not this one. Pointing it at the live directory is the same mistake as deleting by hand with extra steps.
If the pressure is coming from a slot, the decision to drop it is a real one with its own consequences, covered in can I drop a replication slot safely. Replication lag and slot health covers alerting on the retention distance early enough that none of this is urgent, and the write-ahead log covers why those files are the one thing the server cannot be talked out of needing.