[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Zachary Ware added the comment: As far as I can tell from the commit history associated with this issue this seems to have not been a bug, so I'm closing it. If anyone disagrees, please reopen :) -- nosy: +zach.ware resolution: -> not a bug stage: needs patch -> resolved status: op

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Roundup Robot added the comment: New changeset 74a68d86569c by Benjamin Peterson in branch '2.7': revert dd13098a5dc2 (#29006, #10513) https://hg.python.org/cpython/rev/74a68d86569c -- ___ Python tracker __

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: larry: unless someone else comments, I think now that the current status of 3.5.3 is fine enough (nothing was done in this branch, and the problem I describe and just fixed in PyPy can be left for later). The revert dd13098a5dc2 needs to be itself reverted in the

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: Hoping to tag in less than 48 hours...! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: Managed to write a patch in PyPy that seems to pass all tests including the new one, including on Windows. I know think that dd13098a5dc2 should be backed out (i.e. 030e100f048a should be kept). Reference to the PyPy changes: https://bitbucket.org/pypy/pypy/comm

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: ...hah, of course the commit dd13098a5dc2 also reverted away the new test. That test fails. Sorry about that, and feel free to redo that commit. It's just one more case in which the implicit refcounting is used, but I guess as it fixes a real issue it's a good

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: Gian-Carlo is right: I can modify the 2.6 tests in the same way as I described, and then I get the same error with python2.6. So it seems that all of 2.6 was prone to the same issue, and it was never found, but went away in 2.7 accidentally. That seems to mean t

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Gian-Carlo Pascutto added the comment: >Then we wait for someone that really knows why the change was done in the >first place. Python 2.7 had a regression compared to 2.6 where a SELECT after a COMMIT would silently return the wrong data: http://bugs.python.org/issue23129 http://bugs.python.

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Roundup Robot added the comment: New changeset dd13098a5dc2 by Benjamin Peterson in branch '2.7': revert 030e100f048a (#29006, #10513) https://hg.python.org/cpython/rev/dd13098a5dc2 -- nosy: +python-dev ___ Python tracker

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: If I had a say, I would indeed revert 030e100f048a (2.7 branch) and 81f614dd8136 (3.5 branch) as well as forward-port the revert to 3.6 and trunk. Then we wait for someone that really knows why the change was done in the first place. --

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: Ping. Hoping to resolve this in time for 3.5.3, which I tag in about four days. -- ___ Python tracker ___ _

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Changes by Aviv Palivoda : -- nosy: +palaviv ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: FYI I'm keeping an eye on this for possible cherry-picking into 3.5.3 final, depending on the resolution. Reverting 030e100f048a work for me, assuming that's a reasonable solution. -- ___ Python tracker

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Marc-Andre Lemburg added the comment: As general comment, I think you'd have to check which operation modes SQLite supports for the case of a transaction commit/rollback in the light of open cursors. ODBC defines the following cases and each data source can specify a different behavior (https

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Changes by Larry Hastings : -- nosy: +larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Berker Peksag added the comment: Thanks for the report. I can also reproduce it with 3.5+. We may want to revert 030e100f048a for the next 2.7 and 3.5 releases if we can't come up with a solution. -- components: +Library (Lib) stage: -> needs patch type: -> behavior versions: +Python

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: Tried that, but reverted because on Windows CheckTypeMapUsage() would fail with SQLITE_MISUSE ("ProgrammingError: database table is locked"). For now PyPy will not implement this 2.7.13 change. I really suspect you can get the same problems on CPython in some ca

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Armin Rigo added the comment: Or maybe it would be enough to change commit() so that if Sqlite fails with "table is locked", pysqlite would reset all cursors and then try again? -- ___ Python tracker _

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Changes by Ned Deily : -- nosy: +benjamin.peterson, berker.peksag, ghaering ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

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(),