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

Reply via email to