maria:10.2-MDEV-19129

Last commit made on 2021-10-08
Get this branch:
git clone -b 10.2-MDEV-19129 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
10.2-MDEV-19129
Repository:
lp:maria

Recent commits

164e84c... by Sergei Krivonos

Xcode compatibility update

c4a58ca... by FX

Apple Silicon is a 64-bit platform

4780201... by Brandon Nesterenko

MDEV-25444: mysql --binary-mode is not able to replay some mysqlbinlog outputs

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

Reviewed By:
============
Andrei Elkin <email address hidden>

1ce35c3... by Brandon Nesterenko

MDEV-25444: mysql --binary-mode is not able to replay some mysqlbinlog outputs

Note: This patch backports commits 10cd281 and 1755ea4 from 10.3.

10cd281:
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

1755ea4:
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 <email address hidden>

d28b118... by Vladislav Vaintroub

Fix MSVC warning with bison 3.8.2

d5a15f0... by sjaakola <email address hidden>

MDEV-24978 crash with transaction on table with no PK and long fulltext column

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 <email address hidden>

b2a5e0f... by Marko Mäkelä

Make innodb.innodb_defrag_stats more deterministic

Let us mask the actual values of the defragmentation-related fields,
because they may vary. Also, remove the dependency on purge,
and instead delete records by a ROLLBACK of INSERT.

3690c54... by Oleksandr "Sanja" Byelkin

MDEV-24454 Crash at change_item_tree

Use in_sum_func (and so nest_level) only in LEX to which SELECT lex belong to

Reduce usage of current_select (because it does not always point on the correct
 SELECT_LEX, for example with prepare.

Change context for all classes inherited from Item_ident (was only for Item_field) in case of pushing down it to HAVING.

Now name resolution context have to have SELECT_LEX reference if the context is present.

Fixed feedback plugin stack usage.

1a62c87... by Jan Lindström

Remove test from galera_fulltext until MDEV-24978 is fixed.

f59f5c4... by Marko Mäkelä

Revert MDEV-25114

Revert 88a4be75a5f3b8d59ac8f6347ff2c197813c05dc and
9d97f92febc89941784d17d59c60275e21140ce0, which had been
prematurely pushed by accident.