Seems like you'd also need to think about priority inversion, if the
"low-priority" backend is holding any locks.
I'm not sure that priority inversion would be right in this scenario, because in that case the IO storm would still be able to exist, in the cases where the slow jobs collide with the need-to-remain-fast (aka real-time) operations on some lock . I'm using pg in a real time environment communicating with many different hardware, which all produce a light load, but all require real time response times, and allowing a proiority inversion would indirectly allow IO storms in those cases, going back to where everything started.
However, if such a mechanism was to be implemented, maybe it (the inversion of priorities) could be left as an option in the configuration, that could be turned on or off. In my case, I would just leave it off, but maybe for some applications they find it useful, knowing that io storms may still appear, given a series of conditions.
In the case where priority inversion is not to be used, I would however still greatly benefit from the slow jobs/fast jobs mechanism, just being extra-careful that the slow jobs, obviously, did not acquire any locks that a fast job would ever require. This alone would be, still, a *huge* feature if it was ever to be introduced, reinforcing the real-time awareness/requirements, that many applications look for today.
