[New-bugs-announce] [issue29006] 2.7.13 _sqlite more prone to "database table is locked"

[Armin Rigo]

New submission from Armin Rigo:

2.7.13 did a small change to the sqlite commit() method, http://bugs.python.org/issue10513, which I think is causing troubles.  I noticed the problem in PyPy, which (with the same change) fails another test in Lib/sqlite3/test/regression.py, CheckTypeMapUsage(), containing this code:

        ...
        con.execute(SELECT)
        con.execute("drop table foo")
        ...

The first execute() method creates a cursor; assuming it is not promptly deleted, its mere existence causes the second execute() method to fail inside Sqlite with "OperationalError: database table is locked".  As a second step, I could reproduce the problem in CPython by changing the test like this:

        ...
        keepalive = con.execute(SELECT)    # the cursor stays alive
        con.execute("drop table foo")
        ...

The reason is that in the commit() done by the second execute(), we no longer reset all this connection's cursors before proceeding.  But depending on the operation, Sqlite may then complain that the "table is locked" by these old cursors.  In other words, this new situation introduced in 2.7.13 potentially makes a few complicated cases crash by "table is locked" on CPython, where they would work fine previously---which is bad IMHO.  About PyPy, many more cases would crash, to the point that we may have no choice but not implement this 2.7.13 change at all.

----------
messages: 283569
nosy: arigo
priority: normal
severity: normal
status: open
title: 2.7.13 _sqlite more prone to "database table is locked"
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________