Well it’s both possible, and has been done. both with mp3s and FLAC, not too long ago. It’s not the format itself, but rather the applications parsing the files that are the target.
CVE-2023-37327: A remote code execution vulnerability in GStreamer’s FLAC file parser caused by an integer overflow. Carefully crafted FLAC files could exploit this flaw to run arbitrary code on the target system
https://nvd.nist.gov/vuln/detail/CVE-2023-37327#%3A~%3Atext=GStreamer+FLAC%2Ccode+on
If you are on HDD then looking at what else is using the same disk, and reducing that usage, may yield some results. Forexample, if /var/log is on the same disk and can’t be avoided, then reducing log volume or batching writes may reduce the “context switches” your HDD has to do. There should be options for I/O limits/throttling/priority in systemd. If you have only postgres on the HDD, I’d consider giving it 90% of the max bandwidth – maybe that’d be more effective than going full throttle and hitting the wall. If you have postgres and some other service fighting for the HDD’s time, these limits could help. Make sure access time tracking is off (or set to relatime).