When using the tsdb.wlog package and its included checkpoint functionality it's possible to leave behind old temporary checkpoint files if an error occurs during the call to Checkpoint after the directory is created. This has often been caused by the processing calling Checkpoint being shutdown before the call can finish. A few checkpoints isn't really a lot of space but overtime they can accumulate causing confusion about why they exist in the first place.
I would propose that when DeleteCheckpoints https://github.com/prometheus/prometheus/blob/main/tsdb/wlog/checkpoint.go#L68-L82 is called it should maintain the responsibility of removing old temporary checkpoints. I have a PR I will open which implements this functionality.
This suggestion is similar to #10245 but that issue references the higher level tsdb/db which uses wlog but without using the Checkpoint functionality.
When using the
tsdb.wlogpackage and its included checkpoint functionality it's possible to leave behind old temporary checkpoint files if an error occurs during the call toCheckpointafter the directory is created. This has often been caused by the processing callingCheckpointbeing shutdown before the call can finish. A few checkpoints isn't really a lot of space but overtime they can accumulate causing confusion about why they exist in the first place.I would propose that when
DeleteCheckpointshttps://github.com/prometheus/prometheus/blob/main/tsdb/wlog/checkpoint.go#L68-L82 is called it should maintain the responsibility of removing old temporary checkpoints. I have a PR I will open which implements this functionality.This suggestion is similar to #10245 but that issue references the higher level
tsdb/dbwhich useswlogbut without using the Checkpoint functionality.