...and make the fix for MDEV-34993 switchable. It is enabled by default
and controlled with @optimizer_adjust_secondary_key_costs=fix_card_multiplier

When calculate_cond_selectivity_for_table() takes into account multi-
column selectivities from range access, it tries to take-into account
that selectivity for some columns may have been already taken into account.

For example, for range access on IDX1 using {kp1, kp2}, the selectivity
of restrictions on "kp2" might have already been taken into account
to some extent.
So, the code tries to "discount" that using rec_per_key[] estimates.

This seems to be wrong and unreliable: the "discounting" may produce a
rselectivity_multiplier number that hints that the overall selectivity
of range access on IDX1 was greater than 1.

Do a conservative fix: if we arrive at conclusion that selectivity of
range access on condition in IDX1 >1.0, clip it down to 1.

likely, a result of auto-merge of two fixes in different versions

storage/connect/tabfmt.cpp:419:24: error: '%.3d' directive writing between 3 and 10 bytes into a region of size 5 [-Werror=format-overflow=]
  419 |       sprintf(buf, "COL%.3d", i+1);

MDEV-24193 UBSAN: sql/sql_acl.cc:9985:29: runtime error: member access within null pointer of type 'struct TABLE' , ASAN: use-after-poison in handle_grant_table

privilege tables do not always have to exist

row_purge_reset_trx_id(): Reserve large enough offsets for accomodating
the maximum width PRIMARY KEY followed by DB_TRX_ID,DB_ROLL_PTR.

Reviewed by: Thirunarayanan Balathandayuthapani

lock_type is writen in the last SELECT of the unit even if it parsed last,
so it should be printed last from the last select of the unit.

Don't allow the referencing key column from NULL TO NOT NULL
when

 1) Foreign key constraint type is ON UPDATE SET NULL
 2) Foreign key constraint type is ON DELETE SET NULL
 3) Foreign key constraint type is UPDATE CASCADE and referenced
 column declared as NULL

Don't allow the referenced key column from NOT NULL to NULL
when foreign key constraint type is UPDATE CASCADE
and referencing key columns doesn't allow NULL values

get_foreign_key_info(): InnoDB sends the information about
nullability of the foreign key fields and referenced key fields.

fk_check_column_changes(): Enforce the above rules for COPY
algorithm

innobase_check_foreign_drop_col(): Checks whether the dropped
column exists in existing foreign key relation

innobase_check_foreign_low() : Enforce the above rules for
INPLACE algorithm

dict_foreign_t::check_fk_constraint_valid(): This is used
by CREATE TABLE statement to check nullability for foreign
key relation.

The method was declared to return an unsigned integer, but it is
really a boolean (and used as such by all callers).

A secondary change is the addition of "const" and "noexcept" to this
method.

In ha_mroonga.cpp, I also added "inline" to the two helper methods of
referenced_by_foreign_key().  This allows the compiler to flatten the
method.

MDEV-33373 part 2: Unexpected ER_FILE_NOT_FOUND upon reading from logging table after crash recovery

CSV engine shoud set my_errno if use it.

MDEV-33373 part 1: Unexpected ER_FILE_NOT_FOUND upon reading from logging table after crash recovery

We have found that my_errno can be "passed" to the next commad in some cases.

It is practically impossible to check/fix all cases of my_errno in the server,
plugins and engines so we will reset it as we reset other errors.

The test case will be fixed by CSV engine fix so will be added with it
(see part2).

Rollback is not supposed to fail. This prevents false failures in
spider rollback.

ha_spider::update_create_info()
ha_spider::append_lock_tables_list()

A fixup of MDEV-26858

Added new test scenario in galera.galera_bf_kill
test to make the issue surface. The tetst scenario has
a multi statement transaction containing a KILL command.
When the KILL is submitted, another transaction is
replicated, which causes BF abort for the KILL command
processing. Handling BF abort rollback while executing
KILL command causes node hanging, in this scenario.

sql_kill() and sql_kill_user() functions have now fix,
to perform implicit commit before starting the KILL command
execution. BEcause of the implicit commit, the KILL execution
will not happen inside transaction context anymore.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Chocolatey package manager installs this one.

SSL_CTX_set_ciphersuites() sets the TLSv1.3 cipher suites.

SSL_CTX_set_cipher_list() sets the ciphers for TLSv1.2 and below.

The current TLS configuration logic will not perform SSL_CTX_set_cipher_list()
to configure TLSv1.2 ciphers if the call to SSL_CTX_set_ciphersuites() was
successful. The call to SSL_CTX_set_ciphersuites() is successful if any TLSv1.3
cipher suite is passed into `--ssl-cipher`.

This is a potential security vulnerability because users trying to restrict
specific secure ciphers for TLSv1.3 and TLSv1.2, would unknowingly still have
the database support insecure TLSv1.2 ciphers.

For example:
If setting `--ssl_cipher=TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256`,
the database would still support all possible TLSv1.2 ciphers rather than only
ECDHE-RSA-AES128-GCM-SHA256.

The solution is to execute both SSL_CTX_set_ciphersuites() and
SSL_CTX_set_cipher_list() even if the first call succeeds.

This allows the configuration of exactly which TLSv1.3 and TLSv1.2 ciphers to
support.

Note that there is 1 behavior change with this. When specifying only TLSv1.3
ciphers to `--ssl-cipher`, the database will not support any TLSv1.2 cipher.
However, this does not impose a security risk and considering TLSv1.3 is the
modern protocol, this behavior should be fine.

All TLSv1.3 ciphers are still supported if only TLSv1.2 ciphers are specified
through `--ssl-cipher`.

All new code of the whole pull request, including one or several files that are
either new files or modified ones, are contributed under the BSD-new license. I
am contributing on behalf of my employer Amazon Web Services, Inc.

It's read for every command execution, and during slave replication
for every applied event.

It's also planned to be used during write set applying, so it means
mostly every server thread is going to compete for the mutex covering
this variable, especially considering how rarely it changes.
Converting wsrep_ready to atomic relaxes the things.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Add wait_until_ready waits after wsrep_on is set on again to
make sure that node is ready for next step before continuing.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Stabilize test by reseting DEBUG_SYNC and add wait_condition
for expected table contents.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

The crash report terminates prematurely when Galera library was
not loaded.

As a fix, check whether the provider is loaded before shutting down
Galera connections.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

Move memory allocations performed during Sys_var_gtid_binlog_state::do_check
to Sys_var_gtid_binlog_state::global_update where they will be freed before
the latter method returns.

A call to

  dbug_print_join_prefix(join_positions, idx, s)

returns a const char* ponter to string with current join prefix,
including the table being added to it.

All the options that where in buildbot, should
be in the server making it accessible to all
without any special invocation.

If WITH_MSAN=ON, we want to make sure that the
compiler options are supported and it will result
in an error if not supported.

We make the -WITH_MSAN=ON append -stdlib=libc++
to the CXX_FLAGS if supported.

With SECURITY_HARDENING options the bootstrap
currently crashes, so for now, we disable SECRUITY_HARDENING
if there is MSAN enable.

Option WITH_DBUG_TRACE has no effect in MSAN builds.

This is a limitation of the view protocol.
Tests were fixed with workaround (via disable/enable service connection)

Each time a listener socket becomes ready, MariaDB calls accept() ten
times (MAX_ACCEPT_RETRY), even if all but the first one return EAGAIN
because there are no more connections.  This causes unnecessary CPU
usage - on our server, the CPU load of that thread, which does nothing
but accept(), saturates one CPU core by ~45%.  The loop should stop
after the first EAGAIN.

Perf report:

    11.01%  mariadbd  libc.so.6          [.] accept4
     6.42%  mariadbd  [kernel.kallsyms]  [k] finish_task_switch.isra.0
     5.50%  mariadbd  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
     5.50%  mariadbd  [kernel.kallsyms]  [k] syscall_enter_from_user_mode
     4.59%  mariadbd  [kernel.kallsyms]  [k] __fget_light
     3.67%  mariadbd  [kernel.kallsyms]  [k] kmem_cache_alloc
     2.75%  mariadbd  [kernel.kallsyms]  [k] fput
     2.75%  mariadbd  [kernel.kallsyms]  [k] mod_objcg_state
     1.83%  mariadbd  [kernel.kallsyms]  [k] __inode_wait_for_writeback
     1.83%  mariadbd  [kernel.kallsyms]  [k] __sys_accept4
     1.83%  mariadbd  [kernel.kallsyms]  [k] _raw_spin_unlock_irq
     1.83%  mariadbd  [kernel.kallsyms]  [k] alloc_inode
     1.83%  mariadbd  [kernel.kallsyms]  [k] call_rcu

put the command line at the end. so that when a very long command line
is truncated, it doesn't take the actual error message with it

set transferfmt in .cnf file like other galera tests do.
otherwise it defaults to socat when mtr detected that only nc is available

Bring info about cause of closing connection in the place where we increment
statistics to do it correctly.

MDEV-32891 Assertion `value <= ((ulonglong) 0xFFFFFFFFL) * 10000ULL' failed in str_to_DDhhmmssff_internal

Fixing the wrong assert.

MDEV-31302 Assertion `mon > 0 && mon < 13' failed in my_time_t sec_since_epoch(int, int, int, int, int, int)

The code erroneously called sec_since_epoch() for dates with zeros,
e.g. '2024-00-01'.
Fixi: adding a test that the date does not have zeros before
calling TIME_to_native().

MDEV-31221 UBSAN runtime error: negation of -9223372036854775808 cannot be represented in type 'long long int' in my_strtoll10_utf32

The code in my_strtoll10_mb2 and my_strtoll10_utf32
could hit undefinite behavior by negation of LONGLONG_MIN.
Fixing to avoid this.

Also, fixing my_strtoll10() in the same style.
The previous reduction produced a redundant warning on
CAST(_latin1'-9223372036854775808' AS SIGNED)

MDEV-28386 UBSAN: runtime error: negation of -X cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself in my_strntoull_8bit on SELECT ... OCT

The code in my_strntoull_8bit() and my_strntoull_mb2_or_mb4()
could hit undefinite behavior by negating of LONGLONG_MIN.
Fixing the code to avoid this.