The issue here is for degenerate joins we should execute the window
function but it is not getting executed in all the cases.

To get the window function values window function needs to be executed
always. This currently does not happen in few cases
where the join would return 0 or 1 row like
  1) IMPOSSIBLE WHERE
  2) MIN/MAX optimization
  3) EMPTY CONST TABLE

The fix is to make sure that window functions get executed
and the temporary table is setup for the execution of window functions

innodb.cmake: restrict -fno-builtin-memcmp for GCC versions older that 4.6
where optimization issue was solved.

MDEV-21189 : Dropping partition with 'wsrep_OSU_method=RSU' and 'SESSION sql_log_bin = 0' cases the galera node to hang

Test cleanup. Best practice for using RSU, is to isolate the node
up-front, so this test did not reflect real world scenario

- post-push to fix the compilation issue

- Moved the recv_sys->heap memory condition inside recv_parse_log_recs().
So that, InnoDB can mark the status as STORE_NO earlier.

- InnoDB uses one third of buffer pool chunk size for reading the redo
log records. In that case, we can avoid the scenario where buffer ran
out of memory issue during recovery.

It's not safe to chenge the THD::thread_id.
So send the thread_id as an argument to the mysql_audit_external_lock.

in 10.1+ one should use

MY_CHECK_AND_SET_COMPILER_FLAG("-Wno-address-of-packed-member")

and it's already done in storage/tokudb/PerconaFT/CMakeLists.txt

A debug assertion that was added in
commit ed0793e0
turns out to be too strict. In the test innodb_gis.rtree_compress,4k
the function is sometimes being invoked by purge for a
spatial index root page that is not a leaf page (PAGE_LEVEL is 1).

If we manually poison memory region, ASAN requires that we manually unpoison
it too. We didn't do it and munmap() didn't do it too. That was the issue.

os_mem_free_large(): unpoison memory region. Just in case.

https://github.com/google/sanitizers/issues/182
https://github.com/llvm/llvm-project/blob/86acaa9457d3957cbe303e1e801f1e727f66ca89/compiler-rt/include/sanitizer/asan_interface.h#L21

Item_ref::val_(datetime|time)_packed() erroneously called
(*ref)->val_(datetime|time)_packed().

- Fixing to call (*ref)->val_(datetime|time)_packed_result().
- Backporting Item::val_(datetime|time)_packed_result() from 10.3.
- Fixing Item_field::get_date_result() to handle null_value in the same
  way how Item_field::get_date() does.

do not fallback to malloc(), always return properly aligned buffer

One may not call memcpy(dst, src=NULL, size), even if size==0.

Remove Query_tables_list::lock_tables_state - it is not used and it causes
errors like this:

sql_lex.h:1675:7: runtime error: load of value 2779096485, which is not a
valid value for type 'enum_lock_tables_state'

Fix wrong typecast

Problem was that wsrep_on was OFF.

Fixed the condition for waking up/creating another thread.

If there is some work to do (if the request queue is not empty),
a thread should be woken or created.

The condition was incorrect since 18c9b345

We cannot have -Werror for third-party submodules because
whenever they break the build we cannot fix it as needed.

The query requires 2 temporary tables for execution, the window function
is always attached to the last temporary table, but in this case the
result field of the window function points to the first temporary table
rather than the last one.
Fixed this by not changing window function items with temporary table
items of the first temporary table.

PR#1127: Fix is_check_constraints.result to be compatibile with 10.3

The patch is done according to the original patch for MDEV-14474
1edd09c325525cba33152 and not one which is merged on server
d526679e.
This patch includes:
- Rename from `is_check_constraint` to `is_check_constraints` to tests
and results
- Per review, change the order of fields in IS check_constraints table by adding
the column `table_name` before `constraint_name`. According to the standard
2006 there is no `table_name` column.
- Original patch and one in `10.3` supports embedded server this patch doesn't
support. After the merge `10.3` will not support also.
- Don't use patch c8b8b01b61 to change the length of `CHECK_CLAUSE` field

PR#1150: MDEV-18440: Information_schema.check_constraints possible data leak

This patch is extension of PR 1127 and includes:
- Check for table grants
- Additional test according to the MDEV specification
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>

crashes on Debian 10

offset_t: this is a type which represents one record offset.
It's unsigned short int.

a lot of functions: replace ulint with offset_t

btr_pcur_restore_position_func(),
page_validate(),
row_ins_scan_sec_index_for_duplicate(),
row_upd_clust_rec_by_insert_inherit_func(),
row_vers_impl_x_locked_low(),
trx_undo_prev_version_build():
  allocate record offsets on the stack instead of waiting for rec_get_offsets()
  to allocate it from mem_heap_t. So, reducing  memory allocations.

RECORD_OFFSET, INDEX_OFFSET:
  now it's less convenient to store pointers in offset_t*
  array. One pointer occupies now several offset_t. And those constant are start
  indexes into array to places where to store pointer values

REC_OFFS_HEADER_SIZE: adjusted for the new reality

REC_OFFS_NORMAL_SIZE:
  increase size from 100 to 300 which means less heap allocations.
  And sizeof(offset_t[REC_OFFS_NORMAL_SIZE]) now is 600 bytes which
  is smaller than previous 800 bytes.

REC_OFFS_SEC_INDEX_SIZE: adjusted for the new reality

rem0rec.h, rem0rec.ic, rem0rec.cc:
  various arguments, return values and local variables types were changed to
  fix numerous integer conversions issues.

enum field_type_t:
  offset types concept was introduces which replaces old offset flags stuff.
  Like in earlier version, 2 upper bits are used to store offset type.
  And this enum represents those types.

REC_OFFS_SQL_NULL, REC_OFFS_MASK: removed

get_type(), set_type(), get_value(), combine():
  these are convenience functions to work with offsets and it's types

rec_offs_base()[0]:
  still uses an old scheme with flags REC_OFFS_COMPACT and REC_OFFS_EXTERNAL

rec_offs_base()[i]:
  these have type offset_t now. Two upper bits contains type.

copy thread)

mariabackup hangs waiting until innodb redo log thread read log till certain
LSN, and it waits under FTWRL. If there is redo log read error in the thread,
it is finished, and main thread knows nothing about it, what leads to hanging.
As it hangs under FTWRL, slave threads on server side can be blocked due
to MDL lock conflict.

The fix is to finish mariabackup with error message on innodb redo log read
failure.

The issue here is window function makes the passed string object
to point to an area in a temporary table's record buffer.
Then, the temporary table is freed, together with its record buffer.
Then, Item_cache_str attempts to read this value.

The fix is to call value_buff.copy(). This will make the value_buff to store
its string in a buffer that it owns, which will not disappear unexpectedly.

Simplify loading messages into mariabackup. Do the same as server does
We're forcing english, so there is no attempt to load errmsg.sys

When using huge pages, the innodb_buffer_pool_size cannot necessarily
be restored. Simplify things by restarting the server.

InnoDB RNG maintains global state, causing otherwise unnecessary bus
traffic. Even worse, this is cross-mutex traffic. That is, different
mutexes suffer from contention.

Fixed delay of 4 was verified to give best throughput by OLTP update
index and read-write benchmarks on Intel Broadwell (2/20/40) and
ARM (1/46/46).

This is a backport of ce047900 from
MariaDB Server 10.3.

We should not need anywhere near 32 bits of entropy, so we might
just limit ourselves to a 32-bit random number generator.

Also, it might be cheaper to use exclusive-or, bit shifting and
conditional jumps, instead of multiplication and addition.

We use relaxed atomic operations on the global random number generator
state in order in an attempt to silence any warnings about race conditions.
There is an obvious race condition between the load and store in
ut_rnd_gen(), but we do not think that it matters much that the
state of the random number generator could 'stutter'.

This change seems makes the 'uncompress_ops' nondeterministic
in innodb_zip.cmp_per_index after the restart. It looks like
there is an inherent race condition in the test, because the
table could be opened for InnoDB statistics recalculation
already before innodb_cmp_per_index_enabled was set. We might
end up having uncompress_ops anywhere between 0 and 9, or perhaps
even more. Let us remove that part of the test.