Message4425
We get this on the Mercurial project when we close bugs in commit
messages. We have a robot that scans each commit for the close signature
and fires off an email to our bts mail gateway. Each message to the
gateway starts a separate roundup process.
We hit this race quite consistently. I think this is helped by Postfix,
which scans its input queues on a timer, and thus consistently fires off
messages simultaneously on different cores.
As I understand sqlite3/pysqlite's locking model, pysqlite opens the
database in shared mode and automatically opens and closes transactions
for certain kinds of SQL statements. So we end up with multiple
processes looking up the msgid simultaneously, adding one, then doing
write transactions (that succeed). Then we next go on to try to insert
two messages with the same message id and fail on the second one.
There's nothing anywhere in the sqlite backend that looks like locking. |
|
Date |
User |
Action |
Args |
2011-09-16 16:21:13 | mpm | set | messageid: <1316190073.94.0.753490101055.issue2550727@psf.upfronthosting.co.za> |
2011-09-16 16:21:13 | mpm | set | recipients:
+ mpm, ber |
2011-09-16 16:21:13 | mpm | link | issue2550727 messages |
2011-09-16 16:21:13 | mpm | create | |
|