[sqlite] [BUG] sqlite3_exec BEGIN; ROLLBACK corrupts statement already running
Consider the following operations (full test program attached): stmt - prepare conn SELECT * FROM foo Row - step stmt exec conn BEGIN; ROLLBACK Row - step stmt Namely, we prepare a statement with sqlite3_prepare_v2, call sqlite3_step (giving us SQLITE_ROW). While the statement is busy, we jump in and do this: rc = sqlite3_exec(conn, BEGIN; ROLLBACK, NULL, NULL, NULL); On SQLite 3.6.22, this sqlite3_exec call returns SQLITE_BUSY, and the subsequent sqlite3_step returns SQLITE_ROW. On SQLite 3.7.13, this sqlite3_exec call returns SQLITE_OK, but the subsequent sqlite3_step returns SQLITE_ABORT. The latter result looks bogus to me. #define SQLITE_ABORT4 /* Callback routine requested an abort */ We're not doing anything with a callback routine. And according to the documentation for ROLLBACK: The ROLLBACK will fail with an error code SQLITE_BUSY if there are any pending queries. Does this include queries started before the transaction begin? Should it? When the sequence above is performed, I would expect one of two results (preferably the first): * The exec BEGIN; ROLLBACK has no effect on the prepared statement that has already started. * The ROLLBACK fails with SQLITE_BUSY (the 3.6.22 behavior). The 3.7.13 behavior definitely looks wrong. Is this a bug, or is it undefined behavior to BEGIN or ROLLBACK while a prepared statement is running on the same connection? Thanks, -Joey ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [BUG] sqlite3_exec BEGIN; ROLLBACK corrupts statement already running
This is a documented change. See http://www.sqlite.org/releaselog/3_7_11.html: Pending statements no longer block ROLLBACK. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK. There was even some explanation of reasons for that somewhere on the list. Pavel On Thu, Aug 23, 2012 at 9:03 PM, Joey Adams joeyadams3.14...@gmail.com wrote: Consider the following operations (full test program attached): stmt - prepare conn SELECT * FROM foo Row - step stmt exec conn BEGIN; ROLLBACK Row - step stmt Namely, we prepare a statement with sqlite3_prepare_v2, call sqlite3_step (giving us SQLITE_ROW). While the statement is busy, we jump in and do this: rc = sqlite3_exec(conn, BEGIN; ROLLBACK, NULL, NULL, NULL); On SQLite 3.6.22, this sqlite3_exec call returns SQLITE_BUSY, and the subsequent sqlite3_step returns SQLITE_ROW. On SQLite 3.7.13, this sqlite3_exec call returns SQLITE_OK, but the subsequent sqlite3_step returns SQLITE_ABORT. The latter result looks bogus to me. #define SQLITE_ABORT4 /* Callback routine requested an abort */ We're not doing anything with a callback routine. And according to the documentation for ROLLBACK: The ROLLBACK will fail with an error code SQLITE_BUSY if there are any pending queries. Does this include queries started before the transaction begin? Should it? When the sequence above is performed, I would expect one of two results (preferably the first): * The exec BEGIN; ROLLBACK has no effect on the prepared statement that has already started. * The ROLLBACK fails with SQLITE_BUSY (the 3.6.22 behavior). The 3.7.13 behavior definitely looks wrong. Is this a bug, or is it undefined behavior to BEGIN or ROLLBACK while a prepared statement is running on the same connection? Thanks, -Joey ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [BUG] sqlite3_exec BEGIN; ROLLBACK corrupts statement already running
On Fri, Aug 24, 2012 at 12:45 AM, Pavel Ivanov paiva...@gmail.com wrote: This is a documented change. See http://www.sqlite.org/releaselog/3_7_11.html: Pending statements no longer block ROLLBACK. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK. There was even some explanation of reasons for that somewhere on the list. Thanks for the quick response. This looks like the thread you are referring to: http://osdir.com/ml/sqlite-users/2012-04/msg00638.html ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
