/ Check-in [99057383]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix an assert() that can be false for a corrupt database and a strange query that uses a recursive SQL function to delete content from a corrupt database file while it is being queried.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256:99057383acc8f92093530e216c621d40386a06fe98131ff0af6df524d80a6410
User & Date: drh 2018-06-08 19:13:57
Context
2018-06-08
23:23
When the query planner has the opportunity to use an IN operater constraint on a term of an index other than the left-most term, use the estimated number of elements on the right-hand side of the IN operator to determine if makes sense to use the IN operator with index lookups, or to just do a scan over the range of the table identified by the index terms to the left. Only do this if sqlite_stat1 measurements are available as otherwise the performance estimates will not be accurate enough to discern the best plan. Bias the decision slightly in favor of using index lookups on each element of the IN operator. check-in: 2cbbabdf user: drh tags: trunk
19:54
Merge the btreeNext() assertion bug fix from trunk. check-in: 11bd66e0 user: drh tags: in-scan-vs-index
19:13
Fix an assert() that can be false for a corrupt database and a strange query that uses a recursive SQL function to delete content from a corrupt database file while it is being queried. check-in: 99057383 user: drh tags: trunk
2018-06-07
18:13
The IN-early-out optimization: When doing a look-up on a multi-column index and an IN operator is used on a column other than the left-most column, then if no rows match against the first IN value, check to make sure there exist rows that match the columns to the right before continuing with the next IN value. check-in: 09fffbdf user: drh tags: trunk
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to src/btree.c.

  5585   5585         }
  5586   5586         pCur->skipNext = 0;
  5587   5587       }
  5588   5588     }
  5589   5589   
  5590   5590     pPage = pCur->pPage;
  5591   5591     idx = ++pCur->ix;
  5592         -  assert( pPage->isInit );
         5592  +  if( !pPage->isInit ){
         5593  +    /* The only known way for this to happen is for there to be a
         5594  +    ** recursive SQL function that does a DELETE operation as part of a
         5595  +    ** SELECT which deletes content out from under an active cursor
         5596  +    ** in a corrupt database file where the table being DELETE-ed from
         5597  +    ** has pages in common with the table being queried.  See TH3
         5598  +    ** module cov1/btree78.test testcase 220 (2018-06-08) for an
         5599  +    ** example. */
         5600  +    return SQLITE_CORRUPT_BKPT;
         5601  +  }
  5593   5602   
  5594   5603     /* If the database file is corrupt, it is possible for the value of idx 
  5595   5604     ** to be invalid here. This can only occur if a second cursor modifies
  5596   5605     ** the page while cursor pCur is holding a reference to it. Which can
  5597   5606     ** only happen if the database is corrupt in such a way as to link the
  5598   5607     ** page into more than one b-tree structure. */
  5599   5608     testcase( idx>pPage->nCell );