> But we would still have to deal with the > fact that unconditional acquire attempt by the backends will cause a vacuum > to cancel itself, which is undesirable.
Good point. > If we define a new namespace for > this lock (like the relation extension lock has its own namespace) then > perhaps the cancellation code could be made to not cancel on that > condition. But that too seems like a lot of work to backpatch.
We could possibly teach the autocancel logic to distinguish this lock type from others without using a new namespace. That seems a bit klugy, but maybe better than adding a new namespace. (For example, there are probably only a couple of modes in which we take page-level locks at present. Choosing a currently unused, but self-exclusive, mode for taking such a lock might serve.)
Like the attached? (The conditional variant for user backends was unceremoniously yanked out.)
A problem here is that now we have the user backends waiting on vacuum to do the clean up, but vacuum is using throttled IO and so taking its sweet time at it. Under the old code, the user backend could pass up the vacuum while it was sleeping.
Maybe we could have the vacuum detect when someone is waiting on it, and temporarily suspend throttling and just run at full speed. I don't believe there is any precedence for that, but I do think there are other places where such a technique could be useful. That is kind of a scary change to backpatch.