SQLite
Ticket Change Details
Not logged in
Overview

Artifact ID: a12c51a20c2cfac820ad7e37cc67e315c9873252
Ticket: d6b36be38a06c0525731e6357125e6a35ecc4b79
Sub-select in LIMIT clause may access db without locks.
Date: 2012-12-07 18:57:01
User: dan
Changes

  1. Change comment 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>
    
  2. Change detected to "Stress_Testing"
  3. Change foundin to "trunk"
  4. Change severity to "Critical"
  5. Change status to "Open"
  6. Change subsystem to "Code_Generator"
  7. Change title to:
    Sub-select in LIMIT clause may access db without locks.
    
  8. Change type to "Code_Defect"