MariaDB

maria:bb-10.2-alice

  1. Git
  2. lp:maria
  3. bb-10.2-alice
Last commit made on 2021-12-09
Get this branch:
git clone -b bb-10.2-alice https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.2-alice
Repository:
lp:maria

Recent commits

eafa2a1... by Larysa Sherepa

enable partition_open_files_limit test

f974062... by Sergei Krivonos

MDEV-19129: Fixed configure for Xcode, CMake generate

CMake Error in wsrep-lib/CMakeLists.txt:
  The custom command generating

    /Users/name/build/mariadb-server/sql/lex_token.h

  is attached to multiple targets:

    GenServerSource
    sql

  but none of these is a common dependency of the other(s). This is not
  allowed by the Xcode "new build system".

f13c210... by Vladislav Vaintroub

Don't beep in mysql_upgrade_service.exe

This beep looks especially strange, as mysqladmin output is redirected to
the log file

8dd1f01... by Vladislav Vaintroub

MDEV-27191 MariaDB client - "system" command does not work on Windows

- define USE_POPEN, like it is done elsewhere.
- use Notepad as default editor on Windows for the "edit" command.

d5ceddb... by Vladislav Vaintroub

Appveyor - cache chocolatey packages

71027ec... by Sergei Golubchik

fix srpm builds after fe065f8d90b0

214cad8... by Sergei Golubchik

fix ./mtr --manual warning after f5441ef4dac9

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>