With the embedded server library gone, EMBEDDED_LIBRARY is never defined,
and NO_EMBEDDED_ACCESS_CHECKS (which was defined only with it) neither.
Remove the code that was compiled only when they are, and the conditions
that mention them, as if they were never defined:
#ifdef EMBEDDED_LIBRARY the branch is dropped, #else is kept
#ifndef EMBEDDED_LIBRARY the branch is kept, #else is dropped
X && !defined(EMBEDDED_LIBRARY), Y || defined(EMBEDDED_LIBRARY) -> X, Y
No functional change for the server and the clients, which were built
without them. #endif comments that named the macro are corrected.
Done with a script that understands nested conditionals; every rewritten
#if/#elif line was reviewed by hand (two compound conditions that needed
more than that, in sql_parse.cc and log.cc, were fixed by hand).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Caused by Bug#988 in 702b5ad.
How it works
QUERY blocks has all its tables in the array coming after
Query_cache_block header. Each such table element
(Query_cache_block_table) is also an element of doubly-linked circular
list associated with TABLE block used to find all queries by a
table. TABLE block data() is actually Query_cache_table: identificator
for table elements by real name. Every element in the circular list
has `parent` set to such Query_cache_table, except the list root. The
list root is the only Query_cache_block_table element owned by a TABLE
block, all other elements are owned by QUERY blocks. Thus TABLE block
n_tables is always 1.
FREE blocks are transformed into gap pointed by `border`. All the
QUERY and TABLE blocks are moved in place of the gap providing free
space defragmentation. Moving is done by creating new block at the
location of the gap and then doing memmove() from an old block to new
block. This may involve blocks overlap when the distance between the
blocks is less than the block size.
What was broken
When the old and the new QUERY blocks overlap, pointer can be in range
of both of them and checking the range does not guarantee affiliation
of the pointer with the old block. Such intra-block checks added by
Bug#988 can wrongly work on an already updated pointer.
In the test case small gap allows both tables 16 and 17 to be in the
overlapping region of old and new blocks. Iteration 16 updated
`prev->next` on the normal manner and the `prev` was table 17.
Iteration 17 sees this `next` as a pointer coming from an old block
though really it is already for a new block (as small gap shift allows
table 16 to be in both blocks), and it shifts it to the wrong
location. That have broken TABLE block circular chain.
How it was fixed
The fix modifies intra-block checks to work only in the forward
direction. F.ex., current table jx references intra-block by `next`
another table jy in later iteration (jx < jy) and we shift this `next`
pointer. Then by normal code (pre-Bug#988) we update `next->prev`. At
iteration jy we skip intra-block check for `prev` as it is in the past
iteration and was updated by iteration jx. The same happens for the
opposite direction, there is no semantic difference between `next` and
`prev` pointers.
When allocate_block() have failed Query_cache::insert_table() misses
to init node->parent which is then accessed with outdated data. There
is check in Query_cache::register_all_tables():
if (block_table->parent)
unlink_table(block_table);
So unlink_table() is avoided when parent is 0.
Partial commit of the greater MDEV-34348 scope.
MDEV-34348: MariaDB is violating clang-16 -Wcast-function-type-strict
Change the type of my_hash_get_key to:
1) Return const
2) Change the context parameter to be const void*
Also fix casting in hash adjacent areas.
Reviewed By:
============
Marko Mäkelä <marko.makela@mariadb.com>
What's happening:
1. Query_cache::insert() locks the QC and verifies that it's enabled
2. parallel thread tries to disable it. trylock fails (QC is locked)
so the status becomes DISABLE_REQUEST
3. Query_cache::insert() calls Query_cache::write_result_data()
which allocates a new block and unlocks the QC.
4. Query_cache::unlock() notices there are no more QC users and a
pending DISABLE_REQUEST so it disables the QC and frees all the
memory, including the new block that was just allocated
5. Query_cache::write_result_data() proceeds to write into the freed block
Fix: change m_cache_status under a mutex.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
- Changing the global function ok_for_lower_case_names()
into a method in class Lex_ident_fs.
- Changing a few functions/methods to get the database name
as a "const LEX_CSTRING" instead of a "const char *".
All these functions/methods use ok_for_lower_case_names()
inside. This change helps to avoid new strlen() calls, and also
removes a few old strlen() calls.
In commit 28325b0863
a compile-time option was introduced to disable the macros
DBUG_ENTER and DBUG_RETURN or DBUG_VOID_RETURN.
The parameter name WITH_DBUG_TRACE would hint that it also
covers DBUG_PRINT statements. Let us do that: WITH_DBUG_TRACE=OFF
shall disable DBUG_PRINT() as well.
A few InnoDB recovery tests used to check that some output from
DBUG_PRINT("ib_log", ...) is present. We can live without those checks.
Reviewed by: Vladislav Vaintroub
Making changes to wsrep_mysqld.h causes large parts of server code to
be recompiled. The reason is that wsrep_mysqld.h is included by
sql_class.h, even tough very little of wsrep_mysqld.h is needed in
sql_class.h. This commit introduces a new header file, wsrep_on.h,
which is meant to be included from sql_class.h, and contains only
macros and variable declarations used to determine whether wsrep is
enabled.
Also, header wsrep.h should only contain definitions that are also
used outside of sql/. Therefore, move WSREP_TO_ISOLATION* and
WSREP_SYNC_WAIT macros to wsrep_mysqld.h.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
The problem happened because the the new client capability flag
CLIENT_EXTENDED_METADATA was not put into the cache entry key.
So results cached by a new client were sent to the old client (and vica versa)
with a mis-matching metadata, which made the client abort the connection on
an unexpected result set metadata packet format.
The problem was caused by the patch for:
MDEV-17832 Protocol: extensions for Pluggable types and JSON, GEOMETRY
which forgot to adjust the query cache code.
Fix:
- Adding a new member Query_cache_query_flags::client_extended_metadata,
so only clients with equal CLIENT_EXTENDED_METADATA flag values can
reuse results.
- Adding a new column CLIENT_EXTENDED_METADATA into
INFORMATION_SCHEMA.QUERY_CACHE_INFO (privided by the qc_info plugin).
Use < TL_FIRST_WRITE for determining a READ transaction.
Use TL_FIRST_WRITE as the relative operator replacing TL_WRITE_ALLOW_WRITE
as the minimium WRITE lock type.
- Rewrote bool Query_compressed_log_event::write() to make it more readable
(no logic changes).
- Changed DBUG_PRINT of 'is_error:' to 'is_error():' to make it easier to
find error: in traces.
- Ensure that 'db' is never null in Query_log_event (Simplified code).
