contention in UPDATE for some virtual table implementations.
Ticket [56a74875be799b85]
FossilOrigin-Name: eb95dac7f6482c36853a23234c5ce7af37c7beed8e3675d6a49c4d3a8307e076
the result in the encoding of the database. Ticket [0911b5d161b039c6].
Test cases in TH3.
FossilOrigin-Name: f347744e0d576f0250c29259cca755e57afded8956224114c01603c1bca5b3a4
[9ab985a9c8160b90] and [ddb17d92df194337] and other check-ins that those
reference. Fix for ticket [9d708e474201c001]
FossilOrigin-Name: 2c44c73499154bc57634a54cb743642d0aacc93a1336fbb8bb3eb5dbbf616357
by adding the new OP_ReleaseReg opcode to tell MemAboutToChange() that a
range of registers is no longer needed so that the source register can be
freely changed. This is a change to debugging and test builds only and
does not impact release builds. Fix for ticket
[c62c5e58524b204d] and [5ad2aa6921faa1ee]. The previous fix to ticket
[5ad2aa6921faa1ee] is backed out by this change since this change is a better
fix.
FossilOrigin-Name: 36fdeb4f0a66970a35de688b617f90899c89cfdfab659f864df99aa7ebf854ea
OP_Eq and OP_Ne opcode with the same P1 and P3 arguments. This enables us
to back out check-in [ddb17d92df194337] and also fix ticket [188f912b51cd802].
FossilOrigin-Name: 9ab985a9c8160b905730678f40ed440a246cdec549c798bafefaed5abbc0437f
OP_RealAffinity, to avoid problems with a pointer accounting assert.
This change is not strictly necessary - the correct answer is obtained
without it and no UB occurs - however the pointer accounting asserts are
useful to prevent other problems so it is a simple matter to bring this
piece into compliance. Ticket [5ad2aa6921faa1ee]
FossilOrigin-Name: 89a9dad6330270a4c3b962f86a208088d2ea9883c7d291351a77f058e0ed8b0c
table that is in a LEFT JOIN, be sure to set the correct Expr.iRightJoinTable
value. This value does not appear to ever be used, except inside of a single
assert(). But it is good to set it correctly, nevertheless. This fixes
ticket [7929c1efb2d67e98], which as far as I can tell is completely harmless.
FossilOrigin-Name: ef604882a275d3d5ebd4d5a08e3fe43e148f169b7d5c3a81464fbe7f54f3582a
of expressions used in an index-on-expression directly from the index rather
than recomputing the value. If the expression has a top-level COLLATE or
unlikely() operator, be sure to clear the corresponding flags prior to
converting it into a TK_COLUMN expression. Failure to do this is most likely
harmless in production, but might cause an assertion fault in debugging builds.
Ticket [b0cb8aff561a6dcd]. Test cases in TH3.
FossilOrigin-Name: 56539e1c132632c075efc217ad5951a35e4459605ac128914aec3a7be1e25718
as ticket [1b06916e01c82b66] demonstrates a case that refutes them.
FossilOrigin-Name: ddb17d92df194337a103c561ef46ced00db5e67e4551e82de7cb5ad7f457dd5f
constraints if there are any errors, since there might otherwise be attempts
to use those CHECK constraints if PRAGMA writable_schema=ON is set.
This undoes the fix in check-in [ea721b34477ab8b4] for a more general
solution.
FossilOrigin-Name: a982e6434cd66bfbe94d455f538bcbc4360b91572062d92acae6b77e9560e65d
processes the correct entry in the sqlite_master table even if there is
a second entry with the same name and table values due to database corruption
and the use of writable_schema=ON. Dbsqlfuzz find.
FossilOrigin-Name: 4dbb6e1cb094f3428c74ea8bdd86ab63341fecce978a062968ca01423f382e90
(or other expressions in the table definition) might not be fully resolved.
Ensure that the code generator can deal with this if the table is subsequently
used in a DML statement. dbsqlfuzz find.
FossilOrigin-Name: ea721b34477ab8b49d182352c4bc198245933b850e9b6248b4f97600e80bb44b
sequence for the generated column is non-standard.
Part 2 of ticket [e0a8120553f4b082]
FossilOrigin-Name: 056bb8dcbdc45989c5c6e86d2966200062e3c01c382ec52aae37c828104b4496
account the FILTER clause of aggregate functions. Problem reported by
Manuel Rigger.
FossilOrigin-Name: 3cc2b5709e66ef605c3b85ed13ae6cc9c3090e864ebc18859db36284b8f715b6
is seen in the tree. Report the problem immediately, without continuing.
FossilOrigin-Name: 01ca865f31c0c817ede7f357401ef76cf311ae662397908464f53e1c147f5b6b
in the sqlite3WindowRewrite() routine, make sure that pParse->nErr is set,
and make sure that this shuts down any subsequent code generation that might
depend on the transformations that were implemented. This fixes a problem
discovered by the Yongheng and Rui fuzzer.
FossilOrigin-Name: e2bddcd4c55ba3cbe0130332679ff4b048630d0ced9a8899982edb5a3569ba7f
the file being inserted is a NULL. Bug discovered by the
Yongheng and Rui fuzzer.
FossilOrigin-Name: a80f84b511231204658304226de3e075a55afc2e3f39ac063716f7a57f585c06
by disallowing query flattening if the outer query is DISTINCT. Without this fix,
if an index scan is run on the table within the view on the right-hand side of the
LEFT JOIN, stale result registers might be accessed yielding incorrect results,
and/or an OP_IfNullRow opcode might be invoked on the un-opened table, resulting
in a NULL-pointer dereference. This problem was found by the Yongheng and Rui fuzzer.
FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e
INSERT statement. The same assert() appears again in the VDBE and will fire
there if the problem persists in an SQL statement that does not contain
errors. Gramfuzz find.
FossilOrigin-Name: 9bdd57cb9ad8ac1f4a0f1a3942d94ca5193109eeb1975343c4f0c7abf7135946
definitions (see check-in [7e4809eadfe99ebf]) be sure to fully disable
the constant value to avoid an invalid pointer dereference if the expression
is ever duplicated. This fixes a crash report from Yongheng and Rui.
FossilOrigin-Name: 1ca0bd982ab1183bbafce0d260e4dceda5eb766ed2e7793374a88d1ae0bdd2ca
