maria:bb-11.3-vicentiu

Last commit made on 2023-08-29
Get this branch:
git clone -b bb-11.3-vicentiu https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-11.3-vicentiu
Repository:
lp:maria

Recent commits

3096cdb... by Alexander Barkov

MDEV-31303 Key not used when IN clause has both signed and usigned values

Summary:

This patch enables possible index optimization when
the WHERE clause has an IN condition of the form:

signed_or_unsigned_column IN (signed_or_unsigned_constant,
                              signed_or_unsigned_constant
                              [,signed_or_unsigned_constant]*)

when the IN list constants are of different signess, e.g.:
  WHERE signed_column IN (signed_constant, unsigned_constant ...)
  WHERE unsigned_column IN (signed_constant, unsigned_constant ...)

Details:

In a condition like:
   WHERE unsigned_predicant IN (1, LONGLONG_MAX + 1)

comparison handlers for individual (predicant,value) pairs are
calculated as follows:

* unsigned_predicant and 1 produce &type_handler_newdecimal
* unsigned_predicant and (LONGLONG_MAX + 1) produce &type_handler_slonglong

The old code decided that it could not use bisection because
the two pairs had different comparison handlers.
As a result, bisection was not allowed, and, in case of
an indexed integer column predicant the index on the column was not used.

The new code catches special cases like:
    signed_predicant IN (signed_constant, unsigned_constant)
    unsigned_predicant IN (signed_constant, unsigned_constant)

It enables bisection using in_longlong, which supports a mixture
of predicant and values of different signess.
In case when the predicant is an indexed column this change
automatically enables index range optimization.

Thanks to Vicențiu Ciorbaru for proposing the idea and for preparing MTR tests.

e938d7c... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-32028 InnoDB scrubbing doesn't write zero while freeing the extent

Problem:
========
InnoDB fails to mark the page status as FREED during
freeing of an extent of a segment. This behaviour affects
scrubbing and doesn't write all zeroes in file even though
pages are freed.

Solution:
========
InnoDB should mark the page status as FREED before
reinitialize the extent descriptor entry.

aeb8eae... by Marko Mäkelä

Merge 10.4 into 10.5

02878f1... by Marko Mäkelä

MDEV-31813 SET GLOBAL innodb_max_purge_lag_wait hangs if innodb_read_only

innodb_max_purge_lag_wait_update(): Return immediately if we are
in high_level_read_only mode.

srv_wake_purge_thread_if_not_active(): Relax a debug assertion.
If srv_read_only_mode holds, purge_sys.enabled() will not hold
and this function will do nothing.

trx_t::commit_in_memory(): Remove a redundant condition before
invoking srv_wake_purge_thread_if_not_active().

0d88365... by Yuchen Pei <email address hidden>

Merge 10.4 into 10.5

e9f3ca6... by Yuchen Pei <email address hidden>

MDEV-31117 Fix spider connection info parsing

Spider connection string is a comma-separated parameter definitions,
where each definition is of the form "<param_title> <param_value>",
where <param_value> is quote delimited on both ends, with backslashes
acting as an escaping prefix.

Despite the simple syntax, the existing spider connection string
parser was poorly-written, complex, hard to reason and error-prone,
causing issues like the one described in MDEV-31117. For example it
treated param title the same way as param value when assigning, and
have nonsensical fields like delim_title_len and delim_title.

Thus as part of the bugfix, we clean up the spider comment connection
string parsing, including:

- Factoring out some code from the parsing function
- Simplify the struct `st_spider_param_string_parse`
- And any necessary changes caused by the above changes

f9cc298... by Marko Mäkelä

Merge 10.4 into 10.5

ff682ea... by Marko Mäkelä

MDEV-20194 test adjustment for s390x

The test innodb.row_size_error_log_warnings_3 that was added in
commit 372b0e6355fbb6b7dc490b64da13e784c09aeec8 (MDEV-20194)
failed to take into account the earlier adjustment in
commit cf574cf53b168992b911d5fc32c590a6ee03a56a (MDEV-27634)
that is specific to many GNU/Linux distributions for the s390x.

c062b35... by Oleksandr "Sanja" Byelkin

Make vgdb call more universal.

be5fd3e... by Marko Mäkelä

Remove a stale comment

buf_LRU_block_remove_hashed(): Remove a comment that had been added
in mysql/mysql-server@aad1c7d0dd8a152ef6bb685356c68ad9978d686a
and apparently referring to buf_LRU_invalidate_tablespace(),
which was later replaced with buf_LRU_flush_or_remove_pages() and
ultimately with buf_flush_remove_pages() and buf_flush_list_space().
All that code is covered by buf_pool.mutex. The note about releasing
the hash_lock for the buf_pool.page_hash slice would actually apply to
the last reference to hash_lock in buf_LRU_free_page(), for the
case zip=false (retaining a ROW_FORMAT=COMPRESSED page while
discarding the uncompressed one).