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 <rep...@bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
