from gamma

update libmarias3 to get the fix

Analysis: get_defaults_options() rewrites the value for my_defaults_file,
my_defaults_extra_file and  my_defaults_group_suffix to 0. So the config file
can't be read.
Fix: Let handle_options() handle --defaults* option and create a new command
line to pass it to load_defaults().

Set the data member THD::m_prepare_observer temporary to nullptr
to avoid running a handler when a table version in TABLE_LIST
differs from a value of version in TABLE_SHARE. It happens
for any table when the method Ed_connection::execute_direct()
is called from execute_sql_command() since the data members
TABLE_LIST::m_table_ref_type and TABLES_LIST::m_table_ref_version
have zero values on opening a table but corresponding members
of TABLE_SHARE doesn't have. If the function execute_sql_command()
is called on handling a Prepared statement it results in
issuing the error ER_NEED_REPREPARE that is not issued in case the
statement is run in regular way. So, to make fix the issue
reset the data member THD::m_prepare_observer before running
Ed_connection::execute_direct() and restoring it on return.

option which is called from mysql.server (extra_args).

Fix: change mysql.server script to use --defaults-extra-file instead of -e

Analysis: When we have INSERT/REPLACE returning with qualified asterisk in the
RETURNING clause, '*' is not resolved properly because of wrong context.
context->table_list is NULL or has incorrect table because context->table_list
has tables from the FROM clause. For INSERT/REPLACE...SELECT...RETURNING,
context->table_list has table we are inserting from. While in other
INSERT/REPLACE syntax, context->table_list is NULL because there is no FROM
clause.
Fix: If filling fields instead of '*' for qualified asterisk in RETURNING,
use first_name_resolution_table for correct resolution of item.

make code more readable and cleaner.

AIX error message didn't include the filename like:

2021-07-22  9:43:04 0 [ERROR] mariadbd: Can't create/write to file '' (Errcode: 20 "Not a directory")
2021-07-22  9:43:04 0 [ERROR] mariadbd: Can't create/write to file '' (Errcode: 20 "Not a directory")

Reviewer: Marko

row_ins_index_entry_set_vals(): Remove an assertion that trivially
holds because the 16-bit dict_col_t::len cannot represent the value
UNIV_PAGE_SIZE_MAX.

It is implementation-defined whether alignment requirements
that are larger than std::max_align_t (typically 8 or 16 bytes)
will be honored by the compiler and linker.

It turns out that on IBM AIX, both alignas() and MY_ALIGNED()
only guarantees alignment up to 16 bytes.

For some data structures, specifying alignment to the CPU
cache line size (typically 64 or 128 bytes) is a mere performance
optimization, and we do not really care whether the requested
alignment is guaranteed.

But, for the correct operation of direct I/O, we do require that
the buffers be aligned at a block size boundary.

field_ref_zero: Define as a pointer, not an array.
For innochecksum, we can make this point to unaligned memory;
for anything else, we will allocate an aligned buffer from the heap.
This buffer will be used for overwriting freed data pages when
innodb_immediate_scrub_data_uncompressed=ON. And exactly that code
hit an assertion failure on AIX, in the test innodb.innodb_scrub.

log_sys.checkpoint_buf: Define as a pointer to aligned memory
that is allocated from heap.

log_t::file::write_header_durable(): Reuse log_sys.checkpoint_buf
instead of trying to allocate an aligned buffer from the stack.

The lazy deletion of clean blocks from buf_pool.flush_list that was
introduced in commit 6441bc61 (MDEV-25113)
introduced a race condition around the function
buf_flush_relocate_on_flush_list().

The test innodb_zip.wl5522_debug_zip as well as the buffer pool
resizing tests would occasionally fail in debug builds due to
buf_pool.flush_list.count disagreeing with the actual length of the
doubly-linked list.

The safe procedure for relocating a block in buf_pool.flush_list should be
as follows, now that we implement lazy deletion from buf_pool.flush_list:

1. Acquire buf_pool.mutex.
2. Acquire the exclusive buf_pool.page_hash.latch.
3. Acquire buf_pool.flush_list_mutex.
4. Copy the block descriptor.
5. Invoke buf_flush_relocate_on_flush_list().
6. Release buf_pool.flush_list_mutex.

buf_flush_relocate_on_flush_list(): Assert that
buf_pool.flush_list_mutex is being held. Invoke
buf_page_t::oldest_modification() only once, using
std::memory_order_relaxed, now that the mutex protects us.

buf_LRU_free_page(), buf_LRU_block_remove_hashed(): Avoid
an unlock-lock cycle on hash_lock. (We must not acquire hash_lock
while already holding buf_pool.flush_list_mutex, because that
could lead to a deadlock due to latching order violation.)

pmull_supported is not necessarily defined before crc32c_aarch64
Signed-off-by: Nia Alarie <nia@NetBSD.org>

SHOW PLUGINS has a more complete view of the installed
plugins into the server.

The mysql.user is a compatibility view that doesn't
show the complete authentication picture. Use global_priv.

Add `show create user` for default users to more clearly
represent its contents.

We only support the instantaneous removal of the NOT NULL attribute for
ROW_FORMAT=REDUNDANT tables.

The performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" was incorrect. The root cause is the group_mutex was initialized in thread_group_init before registerd in PSI_register(mutex).
The fix is to put PSI_register before thread_group_init, which ensures the right order.

commit the forgotten result file

followup for b81803f0

still cannot be enabled permanently, but at least they
could be run manually, if needed

Also, remove comparison lsn > flush/write lsn, prior to calling
log_write_up_to. The checks and early returns are part of this function.

The problem is that array binding uses net buffer to read parameters for each
execution while each execiting with RETURNING write in the same buffer.

Solution is to allocate new net buffer to avoid changing buffer we are reading
from.

This reverts commit f88d130e.

MDEV-26139 Spider crashes with segmentation fault (signal 11) on CREATE TABLE when COMMENT does not contain embedded double quotes

The root cause of the bug MDEV-26139 is the lack of NULL checking
on the variable `dq`.

Comments on if (dq && (!sq || sq > dq)) {...} else {...}:

  * The if block corresponds to the case where parameters are
    quoted by double quotes. In that case, a single quote doesn't
    appear at all or only appears in the middle of double quotes.

  * The else block corresponds to the case where parameters are
    quoted by single quotes. In that case, a double quote doesn't
    appear at all or only appears in the middle of single quotes.

  * If the program reaches the if-else statement, `sq || dq` holds.
    Thus, the negation of `dq && (!sq || sq > dq)` is equivalent to
    `sq && (!dq || sq <= dq)`.

option which is called from mysql.server (extra_args).

Fix: change mysql.server script to use --defaults-extra-file instead of -e

This bug could affect queries that had at least two references to a CTE that
used an embedded recursive CTE.
Starting from version 10.4 some code in With_element::clone_parsed_spec()
that assumed a certain order of selects after parsing the specification of
a CTE became not valid anymore. It could lead to global select lists where
some selects were missing. If a missing CTE happened to belong to the
recursive part of a recursive CTE some recursive table references were not
set as references to materialized derived tables and this caused a crash of
the server.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

Port the following patch from MySQL:

  commit 1b2e8ea269c80cb93cc79d8be934c40b1c58e947
  Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
  Date:   Fri Nov 30 16:43:13 2018 +0530

    Bug #20939184: INNODB: UNLOCK ROW COULD NOT FIND A 2 MODE
                   LOCK ON THE RECORD

    Issue:
    ------
    Consdier tables t1 and t2 such that t1 has multiple rows
    and join condition for t1 left join t2 results in only
    single row from t2.

    In this case, access to table t2 is const since there
    is a single row that qualifies the join condition.

    However, while executing the query, attempt is made to
    unlock t2's row multiple times.

    The current algorithm to fetch rows approximates to:
    1) Retrieve the row for t1.
    2) Retrieve the row for t2.
    3) Apply the join conditions.
       a) If condition evaluates to true:
          Project the row to the result.
       b) If condition evaluates to false:
          i) If t2's qep_tab->not_null_complement is true,
             unlock t2's row.
          ii) Null-complement the row by calling
              "evaluate_null_complemented_join_record()". In
              this function qep_tab->not_null_complement is
              set to false.

    The t2's only one row, that qualifies join condition,
    is unlocked in Step i) when t1's row is evaluated to
    false.
    When t1's next row is also evaluated to false, another
    attempt is made to unlock t2's already unlocked row.

    This results in following error being logged in error.log:

    "[ERROR] InnoDB: Unlock row could not find a 3 mode lock on
    the record. Current statement:
    select * from t1 left join t2 ......"

    Solution:
    ---------
    When a table's access method is "const", set record unlock
    method for this table to do no operation.

AIX grep doesn't support the grep -A syntax used
in the test case.

--skip-stack-trace isn't there on AIX.

buf_flush_relocate_on_flush_list(): Use dpage->physical_size()
because bpage->zip.ssize may already have been zeroed in
page_zip_set_size() invoked by buf_pool_t::realloc().

This would cause occasional failures of the test
innodb.innodb_buffer_pool_resize, which creates a
ROW_FORMAT=COMPRESSED table.

The replacement of buf_pool.page_hash with a different type of
hash table in commit 5155a300 (MDEV-22871)
introduced a race condition with buffer pool resizing.

We have an execution trace where buf_pool.page_hash.array is changed
to point to something else while page_hash_latch::read_lock() is
executing. The same should also affect page_hash_latch::write_lock().

We fix the race condition by never resizing (and reallocating) the
buf_pool.page_hash. We assume that resizing the buffer pool is
a rare operation. Yes, there might be a performance regression if a
server is first started up with a tiny buffer pool, which is later
enlarged. In that case, the tiny buf_pool.page_hash.array could cause
increased use of the hash bucket lists. That problem can be worked
around by initially starting up the server with a larger buffer pool
and then shrinking that, until changing to a larger size again.

buf_pool_t::resize_hash(): Remove.

buf_pool_t::page_hash_table::lock(): Do not attempt to deal with
hash table resizing. If we really wanted that in a safe manner,
we would probably have to introduce a global rw-lock around the
operation, or at the very least, poll buf_pool.resizing, both of
which would be detrimental to performance.

MDEV-23004 When using GROUP BY with JSON_ARRAYAGG with joint table, the square brackets are not included

make test results stable

followup for 98c7916f

In other ROW_FORMAT than REDUNDANT, the InnoDB record header
size calculation depends on dict_index_t::n_core_null_bytes.

In ROW_FORMAT=REDUNDANT, the record header always is 6 bytes
plus n_fields or 2*n_fields bytes, depending on the maximum
record size. But, during online ALTER TABLE, the log records
in the temporary file always use a format similar to
ROW_FORMAT=DYNAMIC, even omitting the 5-byte fixed-length part
of the header.

While creating a temporary file record for a ROW_FORMAT=REDUNDANT
table, InnoDB must refer to dict_index_t::n_nullable.
The field dict_index_t::n_core_null_bytes is only valid for
other than ROW_FORMAT=REDUNDANT tables.

The bug does not affect MariaDB 10.3, because only
commit 7a27db77 (MDEV-15563)
allowed an ALGORITHM=INSTANT change of a NOT NULL column to
NULL in a ROW_FORMAT=REDUNDANT table.

The fix was developed by Thirunarayanan Balathandayuthapani
and tested by Matthias Leich. The test case was simplified by me.