https://bugzilla.redhat.com/show_bug.cgi?id=1193177
--- Comment #10 from Stuart D Gathman <stu...@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. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=W6X7aC3ux8&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
