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 |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
99057383acc8f92093530e216c621d40 |
| User & Date: | drh 2018-06-08 19:13:57.914 |
References
|
2024-01-28
| ||
| 00:35 | Apply the same fix found in [99057383acc8f920] to descending scans. (check-in: 593d6a1c2e user: drh tags: branch-3.45) | |
| 00:31 | Apply the same fix found in [99057383acc8f920] to descending scans. dbsqlfuzz afd1d61fc27d14938a0d78a50970fa1e9fbfee5. (check-in: e1d463c2d6 user: drh tags: trunk) | |
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: 2cbbabdf5e user: drh tags: trunk) | |
| 19:54 | Merge the btreeNext() assertion bug fix from trunk. (check-in: 11bd66e090 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: 99057383ac 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: 09fffbdf9f user: drh tags: trunk) | |
Changes
Changes to src/btree.c.
| ︙ | ︙ | |||
5585 5586 5587 5588 5589 5590 5591 |
}
pCur->skipNext = 0;
}
}
pPage = pCur->pPage;
idx = ++pCur->ix;
| | > > > > > > > > > | 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 |
}
pCur->skipNext = 0;
}
}
pPage = pCur->pPage;
idx = ++pCur->ix;
if( !pPage->isInit ){
/* The only known way for this to happen is for there to be a
** recursive SQL function that does a DELETE operation as part of a
** SELECT which deletes content out from under an active cursor
** in a corrupt database file where the table being DELETE-ed from
** has pages in common with the table being queried. See TH3
** module cov1/btree78.test testcase 220 (2018-06-08) for an
** example. */
return SQLITE_CORRUPT_BKPT;
}
/* If the database file is corrupt, it is possible for the value of idx
** to be invalid here. This can only occur if a second cursor modifies
** the page while cursor pCur is holding a reference to it. Which can
** only happen if the database is corrupt in such a way as to link the
** page into more than one b-tree structure. */
testcase( idx>pPage->nCell );
|
| ︙ | ︙ |