Overview
Artifact ID: | a12c51a20c2cfac820ad7e37cc67e315c9873252 |
---|---|
Ticket: | d6b36be38a06c0525731e6357125e6a35ecc4b79
Sub-select in LIMIT clause may access db without locks. |
User & Date: | dan 2012-12-07 18:57:01 |
Changes
- comment changed to:
When SQLite processes a SELECT statement for which the FROM clause contains a single sub-select that is not eligible for the flattening optimization, it creates a co-routine that returns one row each time it is invoked to implement the sub-select. The vdbe code is: * Jump to start of main routine, * Body of co-routine, * Main routine (invokes sub-routine). * VerifyCookie routine. Because of the way the SQL compiler works, the VerifyCookie routine is currently being invoked the first time the co-routine is invoked, not by the start of the main routine. If the main routine attempts to access the database before the co-routine is invoked, then it is an error. This may occur if either the LIMIT or the OFFSET expression of the main SELECT are themselves sub-selects that access the database. For example: <verbatim> CREATE TABLE abc(a, b, c); CREATE TABLE def(a, b, c); SELECT * FROM (SELECT * FROM def LIMIT 1 OFFSET 1) LIMIT (SELECT 20 FROM abc) </verbatim>
- Untracked field detected: "Stress_Testing"
- foundin changed to: "trunk"
- severity changed to: "Critical"
- status changed to: "Open"
- subsystem changed to: "Code_Generator"
- title changed to:
Sub-select in LIMIT clause may access db without locks.
- type changed to: "Code_Defect"