Previously, nested transactions were used when a manager returns tasks. That way, there would only be one big COMMIT at the end when all returned tasks had been processed.
This leads to some deadlocks between services and the task queue. So now we will commit after each returned record has been processed.
Additional disk I/O should be small, and is otherwise ameliorated postgres-side by disabling synchronous commits (which I do on production servers).
Description
Previously, nested transactions were used when a manager returns tasks. That way, there would only be one big
COMMIT
at the end when all returned tasks had been processed.This leads to some deadlocks between services and the task queue. So now we will commit after each returned record has been processed.
Additional disk I/O should be small, and is otherwise ameliorated postgres-side by disabling synchronous commits (which I do on production servers).
Changelog description
Commit for every returned task
Status