Commit graph

72278 commits

Author SHA1 Message Date
Jan Lindström
a2fee2da0b MDEV-33928 : Assertion failure on wsrep_thd_is_aborting
Problem was assertion assuming we always hold
THD::LOCK_thd_data mutex that is not true.
In most cases this is true but function is
also used from InnoDB lock manager and
there we can't take THD::LOCK_thd_data to
obey mutex ordering. Removed assertion as
wsrep transaction state can't change even
that case.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-04-22 16:57:48 +02:00
Oleksandr Byelkin
50998a6c6f MDEV-33861 main.query_cache fails with embedded after enabling WITH_PROTECT_STATEMENT_MEMROOT
Synopsis: If SELECT returned answer from Query Cache it is not really executed.

The reason for firing of assertion
  DBUG_ASSERT((mem_root->flags & ROOT_FLAG_READ_ONLY) == 0);
is that in case the query_cache is on and the same query run by different
stored routines the following use case can take place:
First, lets say that bodies of routines used by the test case are the same
and contains the only query 'SELECT * FROM t1';
  call p1() -- a result set is stored in query cache for further use.
  call p2() -- the same query is run against the table t1, that result in
               not running the actual query but using its cached result.
               On finishing execution of this routine, its memory root is
               marked for read only since every SP instruction that this
               routine contains has been executed.
  INSERT INT t1 VALUE (1); -- force following invalidation of query cache
  call p2() -- query the table t1 will result in assertion failure since its
               execution would require allocation on the memory root that
               has been already marked as read only memory root

The root cause of firing the assertion is that memory root of the stored
routine 'p2' was marked as read only although actual execution of the query
contained inside hadn't been performed.

To fix the issue, mark a SP instruction as not yet run in case its execution
doesn't result in real query processing and a result set got from query cache
instead.

Note that, this issue relates server built in debug mode AND with the protect
statement memory root feature turned on. It doesn't affect server built
in release mode.
2024-04-16 08:52:51 +02:00
Yuchen Pei
a73c3f1077
MDEV-21007 Do not assert auto_increment_value unless all parts open
Commit 6dce6aeceb breaks out of a loop
in ha_partition::info when some partitions aren't opened, in which
case auto_increment_value assertion will fail. This commit patches
that hole.
2024-04-08 16:35:21 +10:00
Yuchen Pei
f9e0ebeca4
MDEV-33742 Do not create group by handler when all tables are constant 2024-04-08 14:35:36 +10:00
Sergei Petrunia
8cc36fb743 MDEV-21102: Server crashes in JOIN_CACHE::write_record_data upon EXPLAIN with subqueries
JOIN_CACHE has a light-weight initialization mode that's targeted at
EXPLAINs. In that mode, JOIN_CACHE objects are not able to execute.

Light-weight mode was used whenever the statement was an EXPLAIN. However
the EXPLAIN can execute subqueries, provided they enumerate less than
@@expensive_subquery_limit rows.

Make sure we use light-weight initialization mode only when the select is
more expensive @@expensive_subquery_limit.

Also add an assert into JOIN_CACHE::put_record() which prevents its use
if it was initialized for EXPLAIN only.
2024-04-04 10:30:09 +03:00
Daniele Sciascia
a618ff2b1c MDEV-33216 stack-use-after-return in Wsrep_schema_impl::open_table()
Fix a case of stack-use-after-return reported by ASAN in
Wsrep_schema_impl::open_table(). This function has a stack allocated
TABLE_LIST object and return TABLE_LIST::table to the caller.
Changed the function to take a TABLE_LIST pointer as argument.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-03-28 10:55:37 +01:00
Daniele Sciascia
c71dc39529 MDEV-26499 Fix error "mysql_shutdown failed" during MTR tests
- Fix to avoid mysqltest client getting killed abruptly during
  mysql_shutdown(). When Galera replication is shutdown, wait for
  THDs with `thd->stmt_da()->is_eof()` to disconnect (these are about
  to disconnect anyway).
- Extract duplicate code from `wsrep_stop_replication()` and
  `wsrep_shutdown_replication()` in a new function.
- No need to use a custom `shutdown_mysqld.inc` in galera
  suite. Delete it, so that the one in `mysql-test/include/` is used.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-03-27 04:31:45 +01:00
Vladislav Vaintroub
d695e2de54 MDEV-33506 Show original IP in the "aborted" message.
Add "real ip:<ip_or_localhost>" part to the aborted message
Only for proxy-protocoled connection, so it does not  not to cause
confusion to normal users.
2024-03-26 13:10:36 +01:00
Sergei Petrunia
ed027d65f1 MDEV-33747: Optimization of (SELECT) IN (SELECT ...) executes subquery at prepare stage
Make IN->EXISTS rewrite not to compute constant left expression if it
has a subquery in it.
2024-03-26 12:45:36 +03:00
Marko Mäkelä
9b7c2c6b00 MDEV-33220 fixup: Remove some initialization 2024-03-26 10:47:43 +02:00
Daniele Sciascia
e0c8165487 MDEV-33509 Failed to apply write set with flags=(rollback|pa_unsafe)
Fix function `remove_fragment()` in wsrep_schema so that no error is
raised if the fragment to be removed is not found in the
wsrep_streaming_log table. This is necessary to handle the case where
streaming transaction in idle state is BF aborted. This may result in
the case where the rollbacker thread successfully removes the
transaction's fragments, followed by the applier's attempt to remove
the same fragments. Causing the node to leave the cluster after
reporting a "Failed to apply write set" error.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-03-26 05:56:37 +01:00
Yuchen Pei
ef9cdacf51
MDEV-33220 Fix -wmaybe-uninitialized warnings for g++-13 2024-03-25 12:56:00 +11:00
Marko Mäkelä
59e7289b6c Fix g++-14 -Wmaybe-uninitialized 2024-03-19 08:10:42 +02:00
Marko Mäkelä
2a8c4ccf2e Fix g++-14 -Wtemplate-id-cdtor 2024-03-19 08:09:31 +02:00
Kristian Nielsen
ef7abc881c MDEV-10793: MDEV-33292: main.kill_processlist-6619 fails sporadically in buildbot
There were several races in the main.kill_processlist-6619 testcase:

 - Lingering connections from a previous test case could be visible in SHOW
   PROCESSLIST and cause .result diff.
 - A sync point "dispatch_command_end" was ineffective, as it was consumed at
   the end of the SET DEBUG command itself.
 - The signal from sync point "before_execute_sql_command" could override an
   earlier signal, causing DEBUG_SYNC timeout and test failure.
 - The final SHOW PROCESSLIST could occasionally see a connection in state
   "Busy" instead of the expected "Sleep".

Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2024-03-14 22:48:12 +01:00
Dmitry Shulga
d7758debae MDEV-33218: Assertion `active_arena->is_stmt_prepare_or_first_stmt_execute() || active_arena->state == Query_arena::STMT_SP_QUERY_ARGUMENTS' failed in st_select_lex::fix_prepare_information
In case there is a view that queried from a stored routine or
a prepared statement and this temporary table is dropped between
executions of SP/PS, then it leads to hitting an assertion
at the SELECT_LEX::fix_prepare_information. The fired assertion
 was added by the commit 85f2e4f8e8
(MDEV-32466: Potential memory leak on executing of create view statement).
Firing of this assertion means memory leaking on execution of SP/PS.
Moreover, if the added assert be commented out, different result sets
can be produced by the statement SELECT * FROM the hidden table.

Both hitting the assertion and different result sets have the same root
cause. This cause is usage of temporary table's metadata after the table
itself has been dropped. To fix the issue, reload the cache of stored
routines. To do it  cache of stored routines is reset at the end of
execution of the function dispatch_command(). Next time any stored routine
be called it will be loaded from the table mysql.proc. This happens inside
the method Sp_handler::sp_cache_routine where loading of a stored routine
is performed in case it missed in cache. Loading is performed unconditionally
while previously it was controlled by the parameter lookup_only. By that
reason the signature of the method Sroutine_hash_entry::sp_cache_routine
was changed by removing unused parameter lookup_only.

Clearing of sp caches affects the test main.lock_sync since it forces
opening and locking the table mysql.proc but the test assumes that each
statement locks its tables once during its execution. To keep this invariant
the debug sync points with names "before_lock_tables_takes_lock" and
"after_lock_tables_takes_lock" are not activated on handling the table
mysql.proc
2024-03-14 15:43:03 +07:00
Kristian Nielsen
0a6f46965a MDEV-33475: --gtid-ignore-duplicate can double-apply event in case of parallel replication retry
When rolling back and retrying a transaction in parallel replication, don't
release the domain ownership (for --gtid-ignore-duplicates) as part of the
rollback. Otherwise another master connection could grab the ownership and
double-apply the transaction in parallel with the retry.

Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2024-03-13 16:59:10 +01:00
Dmitry Shulga
ac20edd737 MDEV-33549: Incorrect handling of UPDATE in PS mode in case a table's colum declared as NOT NULL
Follow-up to fix comiler warings caused by present of
the clause override in declaration of the method Item_param::cleanup
2024-03-13 17:46:05 +07:00
Dmitry Shulga
428a673152 MDEV-33549: Incorrect handling of UPDATE in PS mode in case a table's colum declared as NOT NULL
UPDATE statement that is run in PS mode and uses positional parameter
handles columns declared with the clause DEFAULT NULL incorrectly in
case the clause DEFAULT is passed as actual value for the positional
parameter of the prepared statement. Similar issue happens in case
an expression specified in the DEFAULT clause of table's column definition.

The reason for incorrect processing of columns declared as DEFAULT NULL
is that setting of null flag for a field being updated was missed
in implementation of the method Item_param::assign_default().
The reason for incorrect handling of an expression in DEFAULT clause is
also missed saving of a field inside implementation of the method
Item_param::assign_default().
2024-03-12 16:13:49 +07:00
Marko Mäkelä
0a9cec229a MDEV-33642: MemorySanitizer: SEGV on unknown address on shutdown
signal_hand(): Remove the cmake -DWITH_DBUG_TRACE=ON instrumentation.
It can cause a crash on shutdown when the only other thread is
waiting in wait_for_signal_thread_to_end().
2024-03-11 16:14:54 +02:00
Marko Mäkelä
09ea2dc788 MDEV-33209 Stack overflow in main.json_debug_nonembedded due to incorrect debug injection
In the JSON functions, the debug injection for stack overflows is
inaccurate and may cause actual stack overflows. Let us simply
inject stack overflow errors without actually relying on the ability
of check_stack_overrun() to do so.

Reviewed by: Rucha Deodhar
2024-03-11 09:53:04 +02:00
Alexey Botchkov
b93252a303 MDEV-32454 JSON test has problem in view protocol.
Few Item_func_json_xxx::fix_length_and_dec() functions fixed.
2024-03-02 14:58:57 +04:00
Julius Goryavsky
c9b0c006e0 galera: correction after wsrep-lib update
Correction to ensure compatibility with the updated wsrep-lib library.
2024-02-27 09:48:26 +01:00
Alexander Barkov
1b37cb71f4 MDEV-32975 Default charset doesn't work with PHP MySQLi extension
When sending the server default collation ID to the client
in the handshake packet, translate a 2-byte collation ID
to the ID of the default collation for the character set.
2024-02-26 15:39:13 +04:00
Oleksandr Byelkin
a5998145ba Record correct mutex (LOCK_STATUS and acl_cache) order for debugging. 2024-02-20 14:18:51 +01:00
Kristian Nielsen
5707f1efda MDEV-33468: Crash due to missing stack overrun check in two recursive functions
Thanks to Yury Chaikou for finding this problem (and the fix).

Reviewed-by: Monty <monty@mariadb.org>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2024-02-16 12:48:30 +01:00
Kristian Nielsen
fdaa7a96ed MDEV-33443: Unsafe use of LOCK_thd_kill in my_malloc_size_cb_func()
my_malloc_size_cb_func() can be called from contexts where it is not safe to
wait for LOCK_thd_kill, for example while holding LOCK_plugin. This could
lead to (probably very unlikely) deadlock of the server.

Fix by skipping the enforcement of --max-session-mem-used in the rare cases
when LOCK_thd_kill cannot be obtained. The limit will instead be enforced on
the following memory allocation. This does not significantly degrade the
behaviour of --max-session-mem-used; that limit is in any case only enforced
"softly", not taking effect until the next point at which the thread does a
check_killed().

Reviewed-by: Monty <monty@mariadb.org>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2024-02-16 12:48:30 +01:00
Kristian Nielsen
c73c6aea63 MDEV-33426: Aria temptables wrong thread-specific memory accounting in slave thread
Aria temporary tables account allocated memory as specific to the current
THD. But this fails for slave threads, where the temporary tables need to be
detached from any specific THD.

Introduce a new flag to mark temporary tables in replication as "global",
and use that inside Aria to not account memory allocations as thread
specific for such tables.

Based on original suggestion by Monty.

Reviewed-by: Monty <monty@mariadb.org>
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2024-02-16 12:48:30 +01:00
Yuchen Pei
c37216de64 MDEV-33441 Do not deinit plugin variables when retry requested
After MDEV-31400, plugins are allowed to ask for retries when failing
initialisation. However, such failures also cause plugin system
variables to be deleted (plugin_variables_deinit()) before retrying
and are not re-added during retry.

We fix this by checking that if the plugin has requested a retry the
variables are not deleted. Because plugin_deinitialize() also calls
plugin_variables_deinit(), if the retry fails, the variables will
still be deleted.

Alternatives considered:

- remove the plugin_variables_deinit() from plugin_initialize() error
handling altogether. We decide to take a more conservative approach
here.

- re-add the system variables during retry. It is more complicated
than simply iterating over plugin->system_vars and call
my_hash_insert(). For example we will need to assign values to
the test_load field and extract more code from test_plugin_options(),
if that is possible.
2024-02-12 16:36:36 +01:00
Rex
36f51d9748 MDEV-29179 Condition pushdown from HAVING into WHERE is not shown in optimizer trace
JOIN::optimize_inner(), Condition pushdown from HAVING into WHERE
	  not shown in optimizer trace.
2024-02-11 22:21:32 +01:00
Dmitry Shulga
e48bd474a2 MDEV-15703: Crash in EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING DEFAULT
This patch fixes the issue with passing the DEFAULT or IGNORE values to
positional parameters for some kind of SQL statements to be executed
as prepared statements.

The main idea of the patch is to associate an actual value being passed
by the USING clause with the positional parameter represented by
the Item_param class. Such association must be performed on execution of
UPDATE statement in PS/SP mode. Other corner cases that results in
server crash is on handling CREATE TABLE when positional parameter
placed after the DEFAULT clause or CALL statement and passing either
the value DEFAULT or IGNORE as an actual value for the positional parameter.
This case is fixed by checking whether an error is set in diagnostics
area at the function pack_vcols() on return from the function pack_expression()
2024-02-08 09:21:54 +01:00
Dmitry Shulga
6b2cd78695 MDEV-15703: Crash in EXECUTE IMMEDIATE 'CREATE OR REPLACE TABLE t1 (a INT DEFAULT ?)' USING DEFAULT, UBSAN runtime error: member call on null pointer of type 'struct TABLE_LIST' in Item_param::save_in_field
This is the prerequisite patch to refactor the method
  Item_default_value::fix_fields.
The former implementation of this method was extracted and placed
into the standalone function make_default_field() and the method
Item_default_value::tie_field(). The motivation for this modification
is upcoming changes for core implementation of the task MDEV-15703
since these functions will be used from several places within
the source code.
2024-02-08 09:21:42 +01:00
Oleksandr Byelkin
8adc759988 Merge branch '10.4' into mariadb-10.4.33 2024-02-06 15:58:12 +01:00
Oleksandr Byelkin
908c9cf90c workaround for MDEV-33218 2024-01-30 17:00:15 +01:00
Monty
57ffcd686f MDEV-21472: ALTER TABLE ... ANALYZE PARTITION ... with EITS reads and locks all rows
This was fixed in 10.2 in 2020 but merging the code to 10.3 caused the
bug to come back.
2024-01-30 09:19:01 +02:00
Brandon Nesterenko
c75905cacb MDEV-33327: rpl_seconds_behind_master_spike Sensitive to IO Thread Stop Position
rpl.rpl_seconds_behind_master_spike uses the DEBUG_SYNC mechanism to
count how many format descriptor events (FDEs) have been executed,
to attempt to pause on a specific relay log FDE after executing
transactions. However, depending on when the IO thread is stopped,
it can send an extra FDE before sending the transactions, forcing
the test to pause before executing any transactions, resulting in a
table not existing, that is attempted to be read for COUNT.

This patch fixes this by no longer counting FDEs, but rather by
programmatically waiting until the SQL thread has executed the
transaction and then automatically activating the DEBUG_SYNC point
to trigger at the next relay log FDE.
2024-01-30 06:58:44 +01:00
Jan Lindström
ddb27a29b1 MDEV-33172 : Galera test case galera_mdl_race unstable
Add wait_condition between debug sync SIGNAL points and other
expected state conditions and refactor actual sync point for
easier to use in test case.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-01-30 00:27:37 +01:00
Brandon Nesterenko
e4f221a5f2 MDEV-33327: rpl_seconds_behind_master_spike Sensitive to IO Thread Stop Position
rpl.rpl_seconds_behind_master_spike uses the DEBUG_SYNC mechanism to
count how many format descriptor events (FDEs) have been executed,
to attempt to pause on a specific relay log FDE after executing
transactions. However, depending on when the IO thread is stopped,
it can send an extra FDE before sending the transactions, forcing
the test to pause before executing any transactions, resulting in a
table not existing, that is attempted to be read for COUNT.

This patch fixes this by no longer counting FDEs, but rather by
programmatically waiting until the SQL thread has executed the
transaction and then automatically activating the DEBUG_SYNC point
to trigger at the next relay log FDE.
2024-01-29 15:17:57 -07:00
Jan Lindström
c768ac6208 MDEV-25731 : Assertion `mode_ == m_local' failed in wsrep::client_state::streaming_params()
Problem was that if wsrep_load_data_splitting was used
streaming replication (SR) parameters were set
for MyISAM table. Galera does not currently support SR for
MyISAM.

Fix is to ignore wsrep_load_data_splitting setting (with
warning) if table is not InnoDB table.

This is 10.4-10.5 case of fix.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-01-29 06:34:46 +01:00
Jan Lindström
daaa16a47f MDEV-25089 : Assertion `error.len > 0' failed in galera::ReplicatorSMM::handle_apply_error()
Problem is that Galera starts TOI (total order isolation) i.e.
it sends query to all nodes. Later it is discovered that
used engine or other feature is not supported by Galera.
Because TOI is executed parallelly in all nodes appliers
could execute given TOI and ignore the error and
start inconsistency voting causing node to leave from
cluster or we might have a crash as reported.

For example SEQUENCE engine does not support GEOMETRY data
type causing either inconsistency between nodes (because
some errors are ignored on applier) or crash.

Fixed my adding new function wsrep_check_support to check
can Galera support provided CREATE TABLE/SEQUENCE before TOI is
started and if not clear error message is provided to
the user.

Currently, not supported cases:

* CREATE TABLE ... AS SELECT when streaming replication is used
* CREATE TABLE ... WITH SYSTEM VERSIONING AS SELECT
* CREATE TABLE ... ENGINE=SEQUENCE
* CREATE SEQUENCE ... ENGINE!=InnoDB
* ALTER TABLE t ... ENGINE!=InnoDB where table t is SEQUENCE

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-01-29 06:34:46 +01:00
Jan Lindström
3228c08fa8 MDEV-22063 : Assertion `0' failed in wsrep::transaction::before_rollback
Problem was that REPLACE was using consistency check that started
TOI and we tried to rollback it.

Do not use wsrep_before_rollback and wsrep_after_rollback if
we are runing consistency check because no writeset keys are
in that case added. Do not allow consistency check usage
if table storage for target table is not InnoDB, instead
give warning. REPLACE|SELECT INTO ... SELECT will use
now TOI if table storage for target table is not InnoDB
to maintain consistency between galera nodes.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
2024-01-29 06:34:46 +01:00
Alexander Barkov
f738cc9876 MDEV-29095 REGEXP_REPLACE treats empty strings different than REPLACE in ORACLE mode
Turning REGEXP_REPLACE into two schema-qualified functions:
- mariadb_schema.regexp_replace()
- oracle_schema.regexp_replace()

Fixing oracle_schema.regexp_replace(subj,pattern,replacement) to treat
NULL in "replacement" as an empty string.

Adding new classes implementing oracle_schema.regexp_replace():
- Item_func_regexp_replace_oracle
- Create_func_regexp_replace_oracle

Adding helper methods:
- String *Item::val_str_null_to_empty(String *to)
- String *Item::val_str_null_to_empty(String *to, bool null_to_empty)

and reusing these methods in both Item_func_replace and
Item_func_regexp_replace.
2024-01-24 10:59:17 +04:00
Igor Babaev
e8041c7065 MDEV-33270 Failure to call SP invoking another SP with parameter requiring type conversion
This patch corrects the fix for MDEV-32569. The latter has not taken into
account the fact not each statement uses the SELECT_LEX structure. In
particular CALL statements do not use such structure. However the parameter
passed to the stored procedure used in such a statement may require an
invocation of Type_std_attributes::agg_item_set_converter().

Approved by Oleksandr Byelkin <sanja@mariadb.com>
2024-01-19 08:38:00 -08:00
Oleksandr Byelkin
f807a9f874 MDEV-31523 Using two temporary tables in OPTIMIZE TABLE lead to crash
Fixed typo in mysql_admin_table which cused call of
close_unused_temporary_table_instances alwas for the first table
instead of the current table.

Added ASSERT that close_unused_temporary_table_instances should not
remove all instances of user created temporary table.
2024-01-11 11:21:32 +01:00
Sergei Golubchik
c6e1ffd1a0 MDEV-33148 A connection can control RAND() in following connection
initialize THD::rand in THD::init() not in THD::THD(),
because the former is also called when a THD is reused -
in COM_CHANGE_USER and in taking a THD from the cache.

Also use current cycle timer for more unpreditability
2024-01-09 15:22:35 +01:00
Alexander Barkov
9322ef03e3 MDEV-32645 CAST(AS UNSIGNED) fails with --view-protocol
Item_float::neg() did not preserve the "presentation" from "this".
So
  CAST(-1e0 AS UNSIGNED)  -- cast from double to unsigned
changes its meaning to:
  CAST(-1 AS UNSIGNED)  -- cast signed to undigned

Fixing Item_float::neg() to construct the new value for
Item_float::presentation as follows:
- if the old value starts with minus, then the minus is truncated:
  '-2e0' -> '2e0'
- otherwise, minus sign followed by its old value:
  '1e0'  -> '-1e0'
2024-01-09 11:44:05 +04:00
Yuchen Pei
ca276a0f3f
MDEV-33169 Reset sequence used fields after check in alter sequence
The bitmap is temporarily flipped to ~0 for the sake of checking all
fields. It needs to be restored because it will be reused in second
and subsequent ps execution.
2024-01-09 09:50:54 +11:00
Marko Mäkelä
613d019497 MDEV-33160 show_status_array() calls various functions via incompatible pointer
In commit b4ff64568c the
signature of mysql_show_var_func was changed, but not all functions
of that type were adjusted.

When the server is configured with `cmake -DWITH_ASAN=ON` and
compiled with clang, runtime errors would be flagged for invoking
functions through an incompatible function pointer.

Reviewed by: Michael 'Monty' Widenius
2024-01-04 12:50:05 +02:00
Igor Babaev
54ed3939f7 MDEV-31657 Crash on query using CTE with the same name as a base table
If a query contained a CTE whose name coincided with the name of one of
the base tables used in the specification of the CTE and the query had at
least two references to this CTE in the specifications of other CTEs then
processing of the query led to unlimited recursion that ultimately caused
a crash of the server.

Any secondary non-recursive reference to a CTE requires creation of a copy
of the CTE specification. All the references to CTEs in this copy must be
resolved. If the specification contains a reference to a base table whose
name coincides with the name of then CTE then it should be ensured that
this reference in no way can be resolved against the name of the CTE.
2024-01-03 09:57:39 -08:00
Marko Mäkelä
96130b1898 MDEV-33157 WSREP: Fix function pointer mismatch
wsrep_plugin_init(), wsrep_plugin_deinit(): Remove these dummy functions
in order to fix an error that would be flagged by cmake -DWITH_UBSAN=ON
when using clang.

wsrep_show_ready(), wsrep_show_bf_aborts(): Correct the signature.
2024-01-03 08:52:50 +02:00