Fast seralizable transactions starving slower ones

Hello!

We have a system with a lot of integrity constraints that are not easily expressed as SQL constraints. We therefore run all writing 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 transactions are much quicker than the other. Since the first COMMIT of colliding seralizable transactions always wins, the shorter 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 it immediately, 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