Re: a heavy duty operation on an "unused" table kills my server

> 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.