Dan, no, they don't, which is why I included "possible". It is probably not seen elsewhere.
We are using SQLite's virtual table feature to implement a query front end for several diverse data storage methods in an OLTP application, with the two writeable stores being memory sections and CTree files. Both do their own table level locking, and SQLite's additional database level locking was creating concurrency issues between otherwise unrelated (trans)actions (e.g. creating a new virtual table via a housekeeping job would block OLTP). This was resolved by suppressing OP_Transaction for virtual tables. OP_Transaction is only generated for statements that involve native tables. Gunter -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Dan Kennedy Gesendet: Freitag, 14. Oktober 2016 20:33 An: sqlite-users@mailinglists.sqlite.org Betreff: Re: [sqlite] Possible Bug in VTable handling in SQLite 3.14.2 On 10/14/2016 04:59 PM, Hick Gunter wrote: > In the vdbeaux.c source, the function > > resolveP2Values(...) > > is not resetting p->readOnly when it encounters an OP_VUpdate opcode > > is not setting p->bIsReader when it encounters an OP_VFilter opcode > > > Additionally, the frunction > > sqlite3VdbeHalt(...) > > is only checking p->bIsReader and omitting to check p->readOnly > > even though the comment claims to check "if the program never started or if > the SQL Statement does not read or write a database file". > > These omissions conspire to make SQLite refrain from calling the xSync and > xCommit entrypoints of the virtual table named in an UPDATE, DELETE or INSERT > statement. Do you have a test case for this? Trying to reproduce here, all VM programs for UPDATE/DELETE/INSERT also contain OP_Transaction opcodes. Which cause Vdbe.bIsReader to be set and so the xSync/xCommit methods are called. Do the VM programs (EXPLAIN output) for whatever statements you're testing with contain the OP_Transaction? Dan. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: h...@scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
