maria:bb-10.2-MDEV-27148-mysqltest-reject

Last commit made on 2022-02-11
Get this branch:
git clone -b bb-10.2-MDEV-27148-mysqltest-reject https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.2-MDEV-27148-mysqltest-reject
Repository:
lp:maria

Recent commits

e95cef9... by Vlad Lesin

MDEV-27148 running multiple instances of mtr with different var dirrectories can cause .reject and generated from .rdiff .result files overwriting

The code which writes .reject file to the location of .result file is
removed. Also tmp dirrectory is located only in tests var directory.

1780216... by Martin Beck <email address hidden>

MDEV-27088: lf unit tests - cycles insufficient

Per bug report, cycles was woefully insufficient to
detect any implementation error.

4e0dcf1... by Martin Beck <email address hidden>

MDEV-27088: Server crash on ARM (WMM architecture) due to missing barriers in lf-hash

MariaDB server crashes on ARM (weak memory model architecture) while
concurrently executing l_find to load node->key and add_to_purgatory
to store node->key = NULL. l_find then uses key (which is NULL), to
pass it to a comparison function.

The specific problem is the out-of-order execution that happens on a
weak memory model architecture. Two essential reorderings are possible,
which need to be prevented.

a) As l_find has no barriers in place between the optimistic read of
the key field lf_hash.cc#L117 and the verification of link lf_hash.cc#L124,
the processor can reorder the load to happen after the while-loop.

In that case, a concurrent thread executing add_to_purgatory on the same
node can be scheduled to store NULL at the key field lf_alloc-pin.c#L253
before key is loaded in l_find.

b) A node is marked as deleted by a CAS in l_delete lf_hash.cc#L247 and
taken off the list with an upfollowing CAS lf_hash.cc#L252. Only if both
CAS succeed, the key field is written to by add_to_purgatory. However,
due to a missing barrier, the relaxed store of key lf_alloc-pin.c#L253
can be moved ahead of the two CAS operations, which makes the value of
the local purgatory list stored by add_to_purgatory visible to all threads
operating on the list. As the node is not marked as deleted yet, the
same error occurs in l_find.

This change three accesses to be atomic.

* optimistic read of key in l_find lf_hash.cc#L117
* read of link for verification lf_hash.cc#L124
* write of key in add_to_purgatory lf_alloc-pin.c#L253

Reviewers: Sergei Vojtovich, Sergei Golubchik

Fixes: MDEV-23510 / d30c1331a18d875e553f3fcf544997e4f33fb943

ac96314... by Igor Babaev

MDEV-26553 NOT IN subquery construct crashing 10.1 and up

This bug was introduced by commit be00e279c6061134a33a8099fd69d4304735d02e
The commit was applied for the task MDEV-6480 that allowed to remove top
level disjuncts from WHERE conditions if the range optimizer evaluated them
as always equal to FALSE/NULL.
If such disjuncts are removed the WHERE condition may become an AND formula
and if this formula contains multiple equalities the field JOIN::item_equal
must be updated to refer to these equalities. The above mentioned commit
forgot to do this and it could cause crashes for some queries.

Approved by Oleksandr Byelkin <email address hidden>

f5441ef... by Sergei Golubchik

MDEV-26972 MTR worker aborts after server restart failure

restore the old behavior where without a debugger mtr does not
wait for mysqld to start. It was broken in feacc0aaf2

a96b428... by Sergei Golubchik

MDEV-26755 innodb.undo_truncate: ilink::assert_linked(): Assertion `prev != 0 && next != 0' failed

close_connections() in mysqld.cc sends a signal to all threads.
But InnoDB is too busy purging, doesn't react immediately.
close_connections() waits 20 seconds, which isn't enough in this
particular case, and then unlinks all threads from
the list and forcibly closes their vio connection.

InnoDB background threads have no vio connection to close, but
they're unlinked all the same. So when later they finally notice
the shutdown request and try to unlink themselves, they fail to
assert that they're still linked.

Fix: don't assert_linked, as another thread can unlink this THD anytime

4ba7478... by Sergei Golubchik

add a test case

MDEV-20330 Combination of "," (comma), cross join and left join fails to parse

f809a4f... by ryancaicse <email address hidden>

MDEV-26558 Fix a deadlock due to cyclic dependence

Fix a potential deadlock bug between locks ctrl_mutex and entry->mutex

ef179da... by Daniel Black

mysql_install_db: remove MySQL references

MySQL documentation isn't going to help our
users and we shouldn't refer to it.

749d8de... by Marc Olivier Bergeron <email address hidden>

MDEV-27066: Fixed scientific notation parsing bug

The bug occurs where the float token containing a dot with an 'e'
notation was dropped from the request completely.

This causes a manner of invalid SQL statements like:

select id 1.e, char 10.e(id 2.e), concat 3.e('a'12356.e,'b'1.e,'c'1.1234e)1.e, 12 1.e*2 1.e, 12 1.e/2 1.e, 12 1.e|2 1.e, 12 1.e^2 1.e, 12 1.e%2 1.e, 12 1.e&2 from test;

To be parsed correctly as if it was:

select id, char(id), concat('a','b','c'), 12*2, 12/2, 12|2, 12^2, 12%2, 12&2 from test.test;

This correct parsing occurs when e is followed by any of:

( ) . , | & % * ^ /