- Add selected tables as shared keys for CTAS certification
- Set proper security context on the replayer thread
- Disallow CTAS command retry
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

This is caused by fact that VARIABLE_VALUE is defined in
variables_fields_info (sql_show.cc) as 2048.
wsrep_provider_options contain few path variables and
this could cause string truncation on deep and long
directory paths.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Problem:
========
- InnoDB fails to free the allocated buffer of stored cursor
when information schema query is interrupted.

Solution:
=========
- In case of error handling, information schema query should free
the allocated buffer to store the cursor.

It is unused, and causing segfaults

Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

- Commit e3bffd57 introduced the change
- Fixed with commit 2d857144 in 10.4 (no removal of
`Wimplicit-fallthrough=2`)
- Fixed with commit 4a75b480 in 10.5+

- Closing PR #2817
Reviewed by: <monty@mariadb.org>

This will avoid issues like MDEV-32486

IDs used in
- spider_alloc_calc_mem_init()
- spider_string::init_calc_mem()
- spider_malloc()
- spider_bulk_alloc_mem()
- spider_bulk_malloc()

The server doesn't use the enforced storage engine in ALTER TABLE
without ENGINE clause to avoid an unwanted engine change.

However, the server tries to use the enforced engine in CREATE
INDEX. As a result, the false positive error is raised. The server
should not apply the enforced engine in CREATE INDEX too.

Lex_ident_sys had no new operator and was used incorrectly in
save_item_list_names(), so leaked memory.

MDEV-20523: rpl.create_or_replace_mix, rpl.create_or_replace_statement failed in buildbot with wrong result

Wait for the disconnect of the other connection to complete, before running
SHOW BINLOG EVENTS. Otherwise the DROP TEMPORARY TABLE that is binlogged
during disconnect may not have appeared yet depending on thread scheduling.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Fix wrong change to rpl.rpl_shutdown_wait_slaves. After shutting down the
master, slaves may or may not succeed in reconnecting depending on the timing
on their reconnect relative to master restart. So don't assume all IO threads
will be running, just restart any slave that needs it.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Fix sporadic test failure in rpl.rpl_ssl1. The test incorrectly did a STOP
SLAVE too early, which could race with the expected 'Access denied' error.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Fix sporadic test failures in rpl.rpl_set_statement_default_master and
rpl.rpl_slave_load_tmpdir_not_exist. A race between START and STOP
SLAVE could leave an error condition that causes test failure after
MDEV-32168.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Test rpl.show_status_stop_slave_race-7126 now fails sporadically
because it is expected to sometimes (but not always) leave an error
condition after slave stop. Fix by explicitly allowing the error
condition in this case.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Fix a start/stop race that causes occasional test failure after more the more
strict error check of MDEV-32168.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Calling SHOW BINLOG EVENTS FROM <offset> with an invalid offset
writes error messages into the server log about invalid reads. The
read errors that occur from this command should only be relayed back
to the user though, and not written into the server log. This is
because they are read-only and have no impact on server operation,
and the client only need be informed to correct the parameter.

This patch fixes this by omitting binary log read errors from the
server when the invocation happens from SHOW BINLOG EVENTS.
Additionally, redundant error messages are omitted when calling the
string based read_log_event from the IO_Cache based read_log_event,
as the later already will report the error of the former.

Reviewed By:
============
Kristian Nielsen <knielsen@knielsen-hq.org>
Andrei Elkin <andrei.elkin@mariadb.com>

To allow cmake -DWITH_ASAN=ON to work out of the box when using
newer compilers, we must increase the default thread stack size.

By design, AddressSanitizer will allocate some "sentinel" areas in
stack frames so that it can better catch buffer overflows, by trapping
access to memory addresses that reside between stack-allocated variables.

Apparently, some parameters related to this have been changed
recently, possibly to allow -fsanitize=address to catch more errors.

This fixes MDEV-30014, MDEV-29456, MDEV-29667, and MDEV-30049.

The server may ask storage engines to unlock when the original sql
command is not UNLOCK. This patch makes sure that spider honours these
requests, so that the server has the correct idea which tables are
locked and which are not.

MDEV-29456, MDEV-29667, MDEV-30049: a later LOCK statement would, as
the first step, unlock locked tables and clear the OPTION_TABLE_LOCK
bit in thd->variables.option_bits, as well as locked_tables_list,
indicating no tables are locked. If Spider does not unlock because the
sql command is not UNLOCK, and if after this the LOCK statement fails
to lock any tables, these indications that no tables are locked
remains, so a later UNLOCK TABLES; statement would not try to unlock
any table. Causing later statements requiring mdl locks to hang on
waiting until lock_wait_timeout (default 1h) has passed.

MDEV-30014: when a LOCK statement tries to lock more than one tables,
say t2 and t3 as in mdev_30014.test, and t2 succeeds but t3 fails, the
sql layer would try to undo by unlocking t2, and again, if Spider does
not honour this request, the sql layer would assume t2 has been
unlocked, but later actions on t2 or t2's remote table could hang on
waiting for the mdl.

Spider populates its lock lists (a hash) in store_lock(), and normally
clears them in the actual lock_tables(). However, if lock_tables()
fails, there's no reset_lock() method for storage engine handlers,
which can cause bad things to happen. For example, if one of the table
involved is dropped and recreated, or simply TRUNCATEd, when executing
LOCK TABLES again, the lock lists would be queried again in
store_lock(), which could cause access to freed space associated with
the dropped table.

Spider GBH's query rewrite of table joins is overly complex and
error-prone. We replace it with something closer to what
dbug_print() (more specifically, print_join()) does, but catered to
spider.

More specifically, we replace the body of
spider_db_mbase_util::append_from_and_tables() with a call to
spider_db_mbase_util::append_join(), and remove downstream append_X
functions.

We make it handle const tables by rewriting them as (select 1). This
fixes the main issue in MDEV-26247.

We also ban semijoin from spider gbh, which fixes MDEV-31645 and
MDEV-30392, as semi-join is an "internal" join, and "semi join" does
not parse, and it is different from "join" in that it deduplicates the
right hand side

Not all queries passed to a group by handler are valid (MDEV-32273),
for example, a join on expr may refer outer fields not in the current
context. We detect this during the handler creation when walking the
join. See also gbh_outer_fields_in_join.test.

It also skips eliminated tables, which fixes MDEV-26193.

Spider gbh query rewrite should get table for fields in a simple way.
Add a method spider_fields::find_table that searches its table holders
to find table for a given field. This way we will be able to get rid
of the first pass during the gbh creation where field_chains and
field_holders are created.

We also check that the field belongs to a spider table while walking
through the query, so we could remove
all_query_fields_are_query_table_members(). However, this requires an
earlier creation of the table_holder so that tables are added before
checking. We do that, and in doing so, also decouple table_holder and
spider_fields

Remove unused methods and fields. Add comments.

Two methods from spider_fields. There are probably more of these
conn_holder related methods that can be removed

reappend_tables_part()
reappend_tables()

- Reviewer: <knielsen@knielsen-hq.org>
            <brandon.nesterenko@mariadb.com>
            <andrei.elkin@mariadb.com>

Originally requested to be infinity, but rolled back to 99%
to allow for a remote ssh connection or the odd needed system
job. This is up from 15% which is the effective default of
DefaultTasksMax.

Thanks Rick Pizzi for the bug report.

MDEV-30064: binlog.binlog_mysqlbinlog_raw_flush sometimes fails with Errcode: 2 "No such file or directory"

Increase a 1-second timeout, which is a bit too small for slow buildbot
builders.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Reset the GTID sequence at the start of test so earlier run tests does not
influence the expected GTID sequence.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Wait for the binlog checkpoint event to fix non-determinism in the testcase.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

The test was missing a wait_for_binlog_checkpoint.inc, making it non-deterministic
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

MDEV-32733: Two JSON related tests running in PS mode fail on server built with -DWITH_PROTECT_STATEMENT_MEMROOT=YES

The tests main.func_json and json.json_no_table fail on server built with
the option -DWITH_PROTECT_STATEMENT_MEMROOT=YES by the reason that a memory
is allocated on the statement's memory root on the second execution of
a query that uses the function json_contains_path().

The reason that a memory is allocated on second execution of a prepared
statement that ivokes the function json_contains_path() is that a memory
allocated on every call of the method Item_json_str_multipath::fix_fields

To fix the issue, memory allocation should be done only once on first
call of the method Item_json_str_multipath::fix_fields. Simmilar issue
take place inside the method Item_func_json_contains_path::fix_fields.
Both methods are modified to make memory allocation only once on its
first execution and later re-use the allocated memory.

Before this patch the memory referenced by the pointers stored in the array
tmp_paths were released by the method Item_func_json_contains_path::cleanup
that is called on finishing execution of a prepared statement. Now that
memory allocation performed inside the method Item_json_str_multipath::fix_fields
is done only once, the item clean up has degenerate form and can be
delegated to the cleanup() method of the base class and memory deallocation
can be performed in the destructor.

The getmntinfo64 interface is deprected in MacOSX12.1.sdk.

Using getmntinfo instead.

Thanks heyingquay for reporting the bug and testing the fix.

This fixes up commit 01031f43

When parsing statements like (SELECT .. FROM ..) ORDER BY <expr>,
there is a step LEX::add_tail_to_query_expression_body_ext_parens()
which calls LEX::wrap_unit_into_derived(). After that the statement
looks like SELECT * FROM (SELECT .. FROM ..), and parser's
Lex_order_limit_lock structure (ORDER BY <expr>) is assigned to
the new SELECT. But what is missing here is that Items in
Lex_order_limit_lock are left with their original name resolution
contexts, and fix_fields() later resolves the names incorrectly.

For example, when processing
  (SELECT * FROM t1 JOIN t2 ON a=b) ORDER BY a
Item_field 'a' in the ORDER BY clause is left with the name resolution
context of the derived table (first_name_resolution_table='t1'), so
it is resolved to 't1.a', which is incorrect.
After LEX::wrap_unit_into_derived() the statement looks like
  SELECT * FROM (SELECT * FROM t1 JOIN t2 ON a=b) AS '__2' ORDER BY a,
and the name resolution context for Item_field 'a' in the ORDER BY
must be set to the wrapping SELECT's one.

This commit fixes the issue by changing context for Items in
Lex_order_limit_lock after LEX::wrap_unit_into_derived().

There are two TABLE objects in each thread: first one is created in
delayed thread by Delayed_insert::open_and_lock_table(), second one is
created in connection thread by Delayed_insert::get_local_table(). It
is copied from the delayed thread table.

When the second table is copied copy-assignment operator copies
vcol_refix_list which is already filled with an item from delayed
thread. Then get_local_table() adds its own item. Thus both tables
contains the same list with two items which is wrong. Then connection
thread finishes and its item freed. Then delayed thread tries to
access it in vcol_cleanup_expr().

The fix just clears vcol_refix_list in the copied table.

Another problem is that copied table contains the same mem_root, any
allocations on it will be invalid if the original table is freed (and
that is indeterministic as it is done in another thread). Since copied
table is allocated in connection THD and lives not longer than
thd->mem_root we may assign its mem_root from thd->mem_root.

Third, it doesn't make sense to do open_and_lock_tables() on NULL
pointer.

mysql_compare_tables() treated all columns non-virtual. Now it
properly checks if the columns are virtual and matches expressions.