Last commit made on 2024-02-27
Get this branch:
git clone -b 10.4

Branch merges

Branch information


Recent commits

c9b0c00... by Julius Goryavsky <email address hidden>

galera: correction after wsrep-lib update

Correction to ensure compatibility with the updated wsrep-lib library.

87abae4... by Julius Goryavsky <email address hidden>

galera: wsrep-lib submodule update


MDEV-19044 Alter table corrupts while applying the modification log

- InnoDB reads the length of the variable length field wrongly
while applying the modification log of instant table.

rec_init_offsets_comp_ordinary(): For the temporary instant
file record, InnoDB should read the length of the variable length
field from the record itself.

1b37cb7... by Alexander Barkov

MDEV-32975 Default charset doesn't work with PHP MySQLi extension

When sending the server default collation ID to the client
in the handshake packet, translate a 2-byte collation ID
to the ID of the default collation for the character set.

a599814... by Oleksandr "Sanja" Byelkin

Record correct mutex (LOCK_STATUS and acl_cache) order for debugging.

8a50598... by Xiaotong Niu <email address hidden>

MDEV-28430: Fix memory barrier missing of lf_alloc on Arm64

When testing MariaDB on Arm64, a stall issue will occur, jira link:

The stall occurs because of an unexpected circular reference in the
LF_PINS->purgatory list which is traversed in lf_pinbox_real_free().

We found that on Arm64, ABA problem in LF_ALLOCATOR->top list was not
solved, and various undefined problems will occur, including circular
reference in LF_PINS->purgatory list.

The following codes are used to solve ABA problem, code copied
from below link.

503 node= allocator->top;
504 lf_pin(pins, 0, node);
505 } while (node != allocator->top && LF_BACKOFF());

1. ABA problem on Arm64
Combine the below steps to analyze how ABA problem occur on Arm64, the
relevant codes in steps are simplified, code line numbers below are in
MariaDB v10.4.
Abnormal case.
Initial state: pin = 0, top = A, top list: A->B

T1 T2
                                step1. write top=B //seq-cst, #L517
                                step2. write A->next= "any"
                                step3. read pin==0 //relaxed, #L295
step1. write pin=A //seq-cst, #L504
step2. read old value of top==A //relaxed, #L505
step3. next=A->next="any" //#L517
                                step4. write A->next=B,top=A //#L420-435
step4. CAS(top,A,next) //#L517
step5. write pin=0 //#L521
Above case is due to T1.step2 reading the old value of top, causing
"T1.step3, T1.step4" and "T2.step4" to occur at the same time, in other
words, they are not mutually exclusive.

It may happen that T2.step4 is sandwiched between T1.step3 and T1.step4,
which cause top to be updated to "any", which may be in-use or invalid

2. Analyze above issue with Dekker's algorithm
Above problem can be mapped to Dekker's algorithm, link is as below
The following extracts the read and write operations on 'top' and 'pin',
and maps them to Dekker's algorithm to analyze the root cause.
Initial state: top = A, pin = 0
T1 T2
store_seq_cst(pin, A) // write pin store_seq_cst(top, B) //write top
rt= load_relaxed(top) // read top rp= load_relaxed(pin) //read pin

if (rt == A && rp == 0) printf("oops\n"); // will "oops" be printed?
How T1 and T2 enter their critical section:
(1) T1, write pin, if T1 reads that top has not been updated, T1 enter
its critical section(T1.step3 and T1.step4, try to obtain 'A', #L517),
otherwise just give up (T1 without priority).
(2) T2, write top, if T2 reads that pin has not been updated, T2 enter
critical section(T2.step4, try to add 'A' to top list again, #L420-435),
otherwise wait until pin!=A (T2 with priority).

In the previous code, due to load 'top' and 'pin' with relaxed semantic,
on arm and ppc, there is no guarantee that the above critical sections
are mutually exclusive, in other words, "oops" will be printed.

This bug only happens on arm and ppc, not x86. On current x86
implementation, load is always seq-cst (relaxed and seq-cst load
generates same machine code), as shown in

3. Fix method
Add sequential-consistency semantic to read 'top' in #L505(T1.step2),
Add sequential-consistency semantic to read "el->pin[i]" in #L295
and #L320.

4. Issue reproduce
Add "delay" after #L503 in lf_alloc-pin.c, When run unit.lf, can quickly
get segment fault because "top" point to an invalid address. For detail,
see comment area of below link.

5. Futher improvement
To make this code more robust and safe on all platforms, we recommend
replacing volatile with C11 atomics and to fix all data races. This will
also make the code easier to reason.

Signed-off-by: Xiaotong Niu <email address hidden>

5707f1e... by Kristian Nielsen

MDEV-33468: Crash due to missing stack overrun check in two recursive functions

Thanks to Yury Chaikou for finding this problem (and the fix).

Reviewed-by: Monty <email address hidden>
Signed-off-by: Kristian Nielsen <email address hidden>

fdaa7a9... by Kristian Nielsen

MDEV-33443: Unsafe use of LOCK_thd_kill in my_malloc_size_cb_func()

my_malloc_size_cb_func() can be called from contexts where it is not safe to
wait for LOCK_thd_kill, for example while holding LOCK_plugin. This could
lead to (probably very unlikely) deadlock of the server.

Fix by skipping the enforcement of --max-session-mem-used in the rare cases
when LOCK_thd_kill cannot be obtained. The limit will instead be enforced on
the following memory allocation. This does not significantly degrade the
behaviour of --max-session-mem-used; that limit is in any case only enforced
"softly", not taking effect until the next point at which the thread does a

Reviewed-by: Monty <email address hidden>
Signed-off-by: Kristian Nielsen <email address hidden>

c73c6ae... by Kristian Nielsen

MDEV-33426: Aria temptables wrong thread-specific memory accounting in slave thread

Aria temporary tables account allocated memory as specific to the current
THD. But this fails for slave threads, where the temporary tables need to be
detached from any specific THD.

Introduce a new flag to mark temporary tables in replication as "global",
and use that inside Aria to not account memory allocations as thread
specific for such tables.

Based on original suggestion by Monty.

Reviewed-by: Monty <email address hidden>
Signed-off-by: Kristian Nielsen <email address hidden>

ae709b6... by Oleksandr "Sanja" Byelkin

fix view protocol in MDEV-29179