https://bugzilla.redhat.com/show_bug.cgi?id=1193177
--- Comment #10 from Stuart D Gathman stuart@gathman.org --- However, there is just one table immediately updated (no reads between BEGIN and UPDATE/INSERT). If that update fails to obtain the lock, we error out correctly with a rollback. There can be no deadlock with just one table locked, so it is equivalent to IMMEDIATE MODE in this instance.
I'm also noticing that the update uses data fetched from a previous _get_all_spam_records(), that was NOT in the transaction. So correctness depends on the dspam lock file. So this transaction is purely an efficiency issue.
With that, I'll quit pontificating until I have an actual test case that breaks it.