Assertion `!pk->has_virtual()' failed in dict_index_build_internal_clust
while creating PRIMARY key longer than possible to store in the page.

This happened because the key was wrongly deduced as Long UNIQUE supported,
however PRIMARY KEY cannot be of that type. The main reason is that
only 8 bytes are used to store the hash, see HA_HASH_FIELD_LENGTH.

This is also why HA_NOSAME flag is removed (and caused the assertion in
turn) in open_table_from_share:
      if (key_info->algorithm == HA_KEY_ALG_LONG_HASH)
      {
        key_part_end++;
        key_info->flags&= ~HA_NOSAME;
      }

To make it unique, the additional check is done by
check_duplicate_long_entries call from ha_write_row, and similar one from
ha_update_row.

PRIMARY key is already forbidden, which is checked by the first test in
main.long_unique, however is_hash_field_needed was wrongly deduced to true
in mysql_prepare_create_table in this particular case.

FIX:

* Improve the check for Key::PRIMARY type
* Simplify is_hash_field_needed deduction for a more neat reading

MySQL-5.7 mysql.user tables have a last_password_changed field.

Because before MariaDB-10.4 remained oblivious to this, the act of creating
users or otherwise changing a users row left the last_password_field with 0.

Running a MariaDB-10.4 instance on this would work correctly, until mysql_upgrade
is run, when this 0 value immediately translates to password expired
state.

MySQL-5.7 relied on the password_expired enum to indicate password
expiry so we aren't going to activate password that were expired in
MySQL-5.7.

Thanks Hans Borresen for the bug report and review of the fix.

Starting from 10.4 AUTH is not part of ACL_USER so changes have to be done
over a copy, and bring in the cache only in case of success.

In commit 1cb218c3 (MDEV-26450)
we introduced the function log_write_and_flush(), which may
compete with log_checkpoint() invoking log_write_flush_to_disk_low()
from another thread.

The assertion n_pending_flushes==1 is too strict.
There is no possibility of a race condition here, because
fil_flush() is protected by fil_system->mutex and the
rest will be protected by log_sys->mutex.

log_write_flush_to_disk_low(), log_write_and_flush():
Relax the assertions to test for a nonzero count.

Update wsrep-lib, and add MTR test case for MDEV-26707
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Also fixes MDEV-24467 Memory not freed after failed INSERT DELAYED

Description:

In case of an error (e.g. data truncation) during mysql_insert()
handling an INSERT DELAYED, the data type specific data in
fields (e.g. Field_blob::value) is not taken over by the delayed
writer thread.

All fields in table_list->table are freed by free_root()
immediately after mysql_insert(). To avoid a memory leak,
we need to free the specific data before exiting mysql_insert()
on error.

The crash happened because my_isalnum() does not support character
sets with mbminlen>1.

The value of "ft_boolean_syntax" is converted to utf8 in do_string_check().
So calling my_isalnum() is combination with "default_charset_info" was wrong.

Adding new parameters (size_t length, CHARSET_INFO *cs) to
ft_boolean_check_syntax_string() and passing self->charset(thd)
as the character set.

The crash happened because Item_aes_crypt::val_str() did not
set the character set of the result.

Co-authored-by: FX Coudert <fxcoudert@gmail.com>

Uninitialized ref_pointer_array[] because setup_fields() got empty
fields list.  mysql_multi_update() for some reason does that by
substituting the fields list with empty total_list for the
mysql_select() call (looks like wrong merge since total_list is not
used anywhere else and is always empty). The fix would be to return
back the original fields list. But this fails update_use_source.test
case:

  --error ER_BAD_FIELD_ERROR
  update v1 set t1c1=2 order by 1;

Actually not failing the above seems to be ok.

The other fix would be to keep resolve_in_select_list false (and that
keeps outer context from being resolved in
Item_ref::fix_fields()). This fix is more consistent with how SELECT
behaves:

  --error ER_SUBQUERY_NO_1_ROW
  select a from t1 where a= (select 2 from t1 having (a = 3));

So this patch implements this fix.

There are two fill_record() functions (lines 8343 and 8618). First one
is used when there are some explicit values, the second one is used
for all implicit values. First one does update_default_fields(), the
second one did not. Added update_default_fields() call to the implicit
version of fill_record().

Second alter subcommand correctly removed VERS_ROW_END flag. We throw
ER_VERS_PERIOD_COLUMNS in such case.

- Cleaned up Vers_parse_info::check_sys_fields();
- Renamed VERS_SYS_START_FLAG, VERS_SYS_END_FLAG to VERS_ROW_START,
  VERS_ROW_END.

If error_reported is not set upper caller open_table_from_share()
throws error ER_NOT_FORM_FILE itself via open_table_error().

On deadlock transaction is rolled back (and trx->state is cleared) but
SELECT continued the loop because evaluate_join_record() ignored the
error status returned from lower join evaluation. val_int() does not
return error status so it is checked by thd->is_error().

Test case was created by Thirunarayanan Balathandayuthapani
<thiru@mariadb.com>

* Handle the (rare) case where the ongoing transaction is aborted, if
  the ongoing transaction is considered orphaned. This happens if the
  node delivers two consecutive primary views with the
* Add ignorable warning to suite.pm
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

In commit 3690c549
this test was not adjusted.

MDEV-21518 : galera.galera_toi_ddl_nonconflicting MTR failed: 1213: Deadlock found when trying to get lock

Add wait condition.

This is a documentation-only patch to refine the description of
binary mode for the mariadb client.

Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>

Actual problem was earlier fixed. This contains only test
case change. We use debug_sync to force concurrent
DML and TRUNCATE.

We should do after_statement only for local transactions.

Note: This patch backports commits 10cd2818 and 1755ea4b from 10.3.

10cd2818:
Problem:- Some binary data is inserted into the table using
Jconnector. When binlog dump of the data is applied using mysql
client it gives syntax error.

Reason:-
After investigating it turns out to be a issue of mysql client not
able to properly handle  \\0 <0 in binary>. In all binary files
where mysql client fails to insert
these 2 bytes are common (0x5c00)

Solution:-
I have changed mysql.cc to include for the possibility that binary
string can have \\0 in it

1755ea4b:
Changes on top of Sachin’s patch. Specifically:
 1) Refined the parsing break condition to only change the parser’s
behavior for parsing strings in binary mode (behavior of \0 outside
of strings is unchanged).
 2) Prefixed binary_zero_insert.test with ‘mysql_’ to more clearly
associate the  purpose of the test.
 3) As the input of the test contains binary zeros (0x5c00),
different text editors can visualize this sequence differently, and
Github would not display it at all. Therefore, the input itself was
consolidated into the test and created out of hex sequences to make
it easier to understand what is happening.
 4) Extended test to validate that the rows which correspond to the
INSERTS with 0x5c00 have the correct binary zero data.

Reviewed By:
============
Andrei Elkin <andrei.elkin@mariadb.com>

MDEV-22708 Assertion `!mysql_bin_log.is_open() || thd.is_current_stmt_binlog_format_row()' failed in Delayed_insert::handle_inserts and in Diagnostics_area::set_eof_status

Function `upgrade_lock_type` should check global binlog_format variable
instead of thread one.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Changes on top of Sachin’s patch. Specifically:
 1) Refined the parsing break condition to only change the parser’s
behavior for parsing strings in binary mode (behavior of \0 outside
of strings is unchanged).
 2) Prefixed binary_zero_insert.test with ‘mysql_’ to more clearly
associate the  purpose of the test.
 3) As the input of the test contains binary zeros (0x5c00),
different text editors can visualize this sequence differently, and
Github would not display it at all. Therefore, the input itself was
consolidated into the test and created out of hex sequences to make
it easier to understand what is happening.
 4) Extended test to validate that the rows which correspond to the
INSERTS with 0x5c00 have the correct binary zero data.

Reviewed By:
===========
Andrei Elkin <andrei.elkin@mariadb.com>

Problem:- Some binary data is inserted into the table using Jconnector. When
binlog dump of the data is applied using mysql cleint it gives syntax error.

Reason:-
After investigating it turns out to be a issue of mysql client not able to properly
handle  \\\0 <0 in binary>. In all binary files where mysql client fails to insert
these 2 bytes are commom (0x5c00)

Solution:-
I have changed mysql.cc to include for the possibility that binary string can
have \\\0 in it

MDEV-22708 Assertion `!mysql_bin_log.is_open() || thd.is_current_stmt_binlog_format_row()' failed in Delayed_insert::handle_inserts and in Diagnostics_area::set_eof_status

Variable wsrep_forced_binlog_format has higher priority than
binlog_format. In situation where STATEMENT is used and DELAYED INSERT
is executing we should fall back to non-delay INSERT.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

Using `innodb_thread_concurrency` will call `wsrep_thd_is_aborting` to
check WSREP thread state. This call should be protected by taking
`LOCK_thd_data` before entering function.
Applier and TOI threads should no be affected with usage of
`innodb_thread_concurrency` variable so returning before any checks.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

If a table has no unique indexes, write set key information will be collected on all columns in the table.
The write set key information has space only for max 3500 bytes for individual column, and if a varchar colummn of such non-primary key table is longer than
 this limit, currently a crash follows.
The fix in this commit, is to truncate key values extracted from such long varhar columns to max 3500 bytes.
This may potentially lead to false positive certification failures for transactions, which operate on separate cluster nodes, and update/insert/delete table rows, which differ only in the part of such long columns after 3500 bytes border.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>