Hello!
We have a system with a lot of integrity constraints that are not easily expressed as SQL constraints. We therefore run
allwriting transactions in serializable isolation, so that our code can make SELECT:s to check the constraints.
We’ve run in to a, well, it’s not a “problem”, because everything is working according to spec. But some of our
transactionsare much quicker than the other. Since the first COMMIT of colliding seralizable transactions always wins,
theshorter transactions starve the slower ones, which are always restarted.
We’re now working on a solution where all transactions start by taking an advisory lock. Normally transactions release
itimmediately, but a transaction which has been restarted multiple times will keep it, preventing any others from
starting.Thereby it will run to completion, normally within a maximum of one more restart.
Are there any other solutions to this starvation problem?
Regards,
/Viktor
