This doesn't happen.
The logfile is a sequentially-written file on storage. When the memtable fills up, it is flushed to a sstfile on storage and the corresponding logfile can be safely deleted.
[...]
Background compaction threads are also used to flush memtable contents to a file on storage. If all background compaction threads are busy doing long-running compactions, then a sudden burst of writes can fill up the memtable(s) quickly, thus stalling new writes. This situation can be avoided by configuring RocksDB to keep a small set of threads explicitly reserved for the sole purpose of flushing memtable to storage.
The WAL is ONLY read after crashing, to fill a new memtable.
Your comment looked like "WAL is sorted and converted to sstable":
> If a WAL file gets too long then a new one is created and the old one is sorted and written to an sstable asynchronously.
- data in WAL segments has to be checkpointed
- no replication slot, physical or logical, may require the WAL file (see the pg_replication_slots view)
- archiving, if configured, has to have archived the file (see pg_stat_archiver)
It used to be more complicated, for historical reasons we used to keep two checkpoints worth of WAL around, but I don't think any supported versions of postgres still have that behavior.
Edit:
What's more mysterious is whether WAL files are removed when not necessary, or whether they're recycled (renamed to be reused). That's indeed a bit hard to get insight to.