maria:bb-10.6.11-pkgtest-MDEV-31185-pins

Last commit made on 2023-05-19
Get this branch:
git clone -b bb-10.6.11-pkgtest-MDEV-31185-pins https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.6.11-pkgtest-MDEV-31185-pins
Repository:
lp:maria

Recent commits

35a7815... by Vlad Lesin

MDEV-31185 rw_trx_hash_t::find() unpins pins too early

rw_trx_hash_t::find() acquires element->mutex, then unpins pins, used for
lf_hash element search. After that the "element" can be deallocated and
reused by some other thread.

If we take a look rw_trx_hash_t::insert()->lf_hash_insert()->lf_alloc_new()
calls, we will not find any element->mutex acquisition, as it was not
initialized yet before it's allocation. rw_trx_hash_t::insert() can reuse
the chunk, unpinned in rw_trx_hash_t::find().

The scenario is the following:

1. Thread 1 have just executed lf_hash_search() in
rw_trx_hash_t::find(), but have not acquired element->mutex yet.
2. Thread 2 have removed the element from hash table with
rw_trx_hash_t::erase() call.
3. Thread 1 acquired element->mutex and unpinned pin 2 pin with
lf_hash_search_unpin(pins) call.
4. Some thread purged memory of the element.
5. Thread 3 reused the memory for the element, filled element->id,
element->trx.
6. Thread 1 crashes with failed "DBUG_ASSERT(trx_id == trx->id)"
assertion.

Note that trx_t objects are also reused, see the code around trx_pools
for details.

The fix is to invoke "lf_hash_search_unpin(pins);" after element->trx is
stored in local variable in rw_trx_hash_t::find().

Reviewed by: Nikita Malyavin, Marko Mäkelä.

8e997f7... by Sergey Petrunia

MDEV-29129: Performance regression starting in 10.6: select order by limit ...

The cause of regression was handling for ROWNUM() function.
For queries like

  SELECT ROWNUM() FROM ... ORDER BY ...

ROWNUM() should be computed before the ORDER BY.
The computation was moved to be before the ORDER BY for any entries in
the select list that had RAND_TABLE_BIT set.

This had a negative impact on queries in form:

  SELECT sp_func() FROM t1 ORDER BY ... LIMIT n

where sp_func() is NOT declared as DETERMINISTIC (and so has
RAND_TABLE_BIT set).

The fix is to require evaluation for sorting only for the ROWNUM()
function. Functions that just have RAND_TABLE_BIT() can be computed
after ORDER BY ... LIMIT is applied.

(think about a possible index that satisfies the ORDER BY clause. In
that case, the the rows would be read in the needed order and we would
stop after reading LIMIT rows, achieving the same effect).

(cherry picked from commit ec96a27bdd03b53a117f5cdc44ad8e722a1d3a9b)

d157b25... by Sergei Golubchik

update colunmstore

e5aa581... by Oleksandr "Sanja" Byelkin

Merge branch '10.5' into 10.6

177d858... by Oleksandr "Sanja" Byelkin

Merge branch '10.4' into 10.5

0946c99... by Oleksandr "Sanja" Byelkin

Merge branch '10.3' into 10.4

3303748... by Oleksandr "Sanja" Byelkin

MDEV-29926: ASAN heap-use-after-free in Explain_query::~Explain_query

Make sure that EXPLAIN object allocated on runtime arena.

1a3859f... by Sergei Golubchik

MDEV-29924 Assertion `(((nr) % (1LL << 24)) % (int) log_10_int[6 - dec]) == 0' failed in my_time_packed_to_binary on SELECT when using TIME field

when assigning the cached item to the Item_cache for the first time
make sure to use Item_cache::setup(), not Item_cache::store().
Because the former copies the metadata (and allocates memory, in case
of Item_cache_row), and Item_cache::decimal must be set for
comparisons to work correctly.

6414374... by Sergei Golubchik

followup: fix ASAN failure of main.having_cond_pushdown --ps

also call top_level_transform() recursively for

(a OR b) AND (c OR d)

a472237... by Sergei Golubchik

followup: fix ASAN failure of main.opt_tvc --ps