I may be staying the obvious but the workaround perhaps would be to set the OS write buffers parms to be brief & quick, low threshold to checkpoint.

Likewise this was the approach I took in the past (ca 1998) w/ DB/2 (first a VLDB implementation on AIX ) was to set the max# of write workers with relatively small buffers. The intent was twofold, to avoid big buffer flushes that made the system pause, & to force writes ASAP.

I also set the WAL segments & checkpoints to relatively brief intervals as well. Back then DB/2's logs streamed via a named pipe (mkfifo) & a compiled C module and set up in such a manner were archived very quickly when throughput was high.

'Course the system had 32 duplex channel SSA discs, 8 GB RAM, & 12 superscalar RISC CPUs...

I implemented this twice actually, one at my state's edu agency , another at a personal finance dotcom.

It was counterintuitive, relied heavily on both *ix & the physical IO channel to keep up, but both times the IBM folks rubber stamped it (2nd time at San Mateo Prime...)...

W/ today's 16x PCI lanes & NVMe drives in the same ball park hardware-wise, that would be the approach I'd take, but perhaps also flush via preset fsync & checkpoints , and if need be, issued via some sort of scheduler/watchdog..

It was pretty brick simple then, not a BFD today either.

-lee