Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View


Categories: connectors experimental galera main
Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

connectors experimental galera main
fc65e7e12ae8...
fc65e7e12ae808b484feff1b5933ad5d57c168d1
Oleksandr Byelkin
Merge branch 'bb-11.8-release' into bb-12.3-release
fafcaa81f983...
fafcaa81f9839684b8f98e0824568634b2960420
Daniel Bartholomew
bump the VERSION
ef3ff19d0c2d...
ef3ff19d0c2da3257533488082de50f29c5273f5
Alexander Barkov
A hack to make sp-in-func2 work

f1() - uses PS
f2() - calls f1()
p2() - calls f2() as an assignment right hand

Note: these test crashes:

rpl.rpl_sp_effects
compat/oracle.sp-row
main.sp-anchor-row-type-table
main.sp-inout
compat/oracle.sp-anchor-row-type-table
compat/oracle.sp-default-param
compat/oracle.sp-inout
ed8404a73f93...
ed8404a73f93e79aff7227bb4560a44cbfdb5d1c
Hemant Dangi
MDEV-39721: wsrep_notify.cc: reject shell-unsafe characters in joiner-supplied member fields

Issue:
wsrep_notify_status() interpolated members[i].name() (the peer's
wsrep_node_name) and members[i].incoming() verbatim into a command
string that is then executed via 'sh -c' by wsp::process. A peer
joining the cluster with shell metacharacters in its wsrep_node_name
or wsrep_node_incoming_address caused arbitrary commands to run on
every cluster member that had wsrep_notify_cmd configured.
MDEV-39413 introduced safe() for the same threat class in the SST
scripts but did not cover the C++ wsrep_notify path.

Solution:
Validate each substituted field against a narrow whitelist before
interpolating. Node name allows alnum and -_. ; node address
additionally allows :[]/ for host:port and [ipv6] forms. On bad
input the notification is skipped with an error log instead of
forwarding the unsafe value to sh -c.
e41fc2243552...
e41fc224355224fe67d3f5d3acae530ba31a4b32
Vladislav Vaintroub
CI - Fix Github Actions warning, bump actions/checkout version
e3d0d66f5b7e...
e3d0d66f5b7e68e6c2eb73b4cb52896bff3996a8
Oleksandr Byelkin
Merge branch 'bb-12.3-release' into bb-13.0-release
e287c48d7327...
e287c48d73272e1618156520c9c18b3768464a1b
Vladislav Vaintroub
improve MTR bootstrap performance on slow disk

use --debug-no-sync to workaround slow disk flush.
On Github actions Windows ARM64, this alone cuts the test time from
ca 55 min to ca 45 min.
dfbc0549549a...
dfbc0549549ab5d3d42f2c0b6eda73051b2ffbe1
Daniel Black
MDEV-33170: ASAN errors upon CONVERT TABLE TO PARTITION with query cache

The ALTER TABLE.. CONVERT TABLE TO invalided the table cache of the
previously normal table that was moved and which left the query cache refering
to a removed table by the time it was invalidated after the ALTER.

Let's invalidate the query cache at the beginning of the fast path for
all variants of the ALTER TABLE (partitioning).

This prevents a use after free ASAN error that was previous there when the
query_cache_invalidate was use on the source table that was freed from the
table cache.

Alternates considered:
* A query cache invalidate early CONVERT_IN and leave the
  fast_end_partition invalidate - still results in ASAN assertion.
* A fast_end_partition with an argument to skip QC clear -
  seemed to treat this special ALTER TABLE too specially.

Review: Sanja Byelkin
de35aa07cbf2...
de35aa07cbf2c3b68ba4ecc14b2d15e9fbe18308
Hemant Dangi
MDEV-38843: disconnect on unexpected applier-thread exit

Issue:
If a wsrep applier's run_applier() returned with anything other than
wsrep::provider::success while the server was not already shutting
down, the apply state machine was broken but the node stayed Primary
and kept receiving write sets it could not apply — silently locking
the cluster.

Solution:
wsrep_replication_process() now treats any non-success return as an
unexpected exit, logs a WSREP_ERROR, and calls
Wsrep_server_state::disconnect() so the cluster stops shipping write
sets to this node. Operator restarts to rejoin via IST/SST.
Operator-initiated wsrep_slave_threads shrink returns success and is
unaffected.
cdccad8a8d94...
cdccad8a8d94f592332ffe8519ba47e25b0d261b
Yuchen Pei
MDEV-15621 Auto add RANGE COLUMNS partitions by interval

Allow auto partitioning by interval in PARTITION BY RANGE COLUMNS

PARTITION BY RANGE COLUMNS (col_name)
INTERVAL interval [AUTO]
(
  PARTITION partition_name VALUES LESS THAN (value)
  [, PARTITION partition_name VALUES LESS THAN (value) ... ]
)

where

- col_name is the name of one column of type DATE or DATETIME or
  TIMESTAMP
- at least one partition is supplied
- INTERVAL interval is a time interval

When performing DML on such a table, it will first add partitions
by the specified interval until the partition covers the current time.

Partition addition will not cause an implicit commit like DDL normally
does.

The partitions are named pN.

Otherwise the table behaves exactly the same as a normal RANGE COLUMNS
partitioned table.

Note that TIMESTAMP is not allowed as a type for PARTITION BY RANGE
COLUMNS otherwise.
cb6b5e26d183...
cb6b5e26d1837c007b87bd4ad676b7c1720ffe8e
Marko Mäkelä
MDEV-39344: fetch_data_into_cache() clears "is_truncated"

There is a memory limit implemented for the INFORMATION_SCHEMA tables
innodb_trx, innodb_locks, innodb_lock_waits. The predicate
trx_i_s_cache_is_truncated() would never hold in
trx_i_s_common_fill_table() due to a logic bug that had been
introduced in a refactoring.

fetch_data_into_cache(): Shrink the critical section of lock_sys.latch
and do not unconditionally reset cache->is_truncated when leaving the
function. This fixes a correctness regression that had been introduced
back in 2007 by commit 5cbf4e3840491c2d80928641bc0fbb8135e9c201
for the InnoDB Plugin for MySQL 5.1, which later became
the built-in InnoDB in MySQL 5.5 and MariaDB Server 5.5.
c711a39d36a2...
c711a39d36a26c76a567852ca2c39412ae5e3f25
Hemant Dangi
MDEV-38843: BF applier failed on a node causing complete Cluster lockup

Issue:
If a wsrep applier's run_applier() returned with anything other than
wsrep::provider::success while the server was not already shutting
down, the apply state machine was broken but the node stayed Primary
and kept receiving write sets it could not apply — silently locking
the cluster.

Solution:
wsrep_replication_process() now treats any non-success return as an
unexpected exit, logs a WSREP_ERROR, and calls
Wsrep_server_state::disconnect() so the cluster stops shipping write
sets to this node. Operator restarts to rejoin via IST/SST.
Operator-initiated wsrep_slave_threads shrink returns success and is
unaffected.
b8706024f1e1...
b8706024f1e125086653b4016c0302c8d2576554
Alexander Barkov
A hack to make sp-in-func2 work

f1() - uses PS
f2() - calls f1()
p2() - calls f2() as an assignment right hand

Note: these test crashes:

rpl.rpl_sp_effects
compat/oracle.sp-row
main.sp-anchor-row-type-table
main.sp-inout
compat/oracle.sp-anchor-row-type-table
compat/oracle.sp-default-param
compat/oracle.sp-inout
b4a80422bfee...
b4a80422bfeec93079a430c080fffbda8f6fa574
Sergei Golubchik
Merge branch '10.11' into 11.4
b2050fdb4a87...
b2050fdb4a8776422baf01a41bf86845994edb97
Sergei Golubchik
strengthen safe() in wsrep_sst_common, just in case
afca217027f1...
afca217027f1b997ae3b3d8ef6ebf40cba2a5c67
Yuchen Pei
MDEV-15621 Auto add RANGE COLUMNS partitions by interval

Allow auto partitioning by interval in PARTITION BY RANGE COLUMNS

PARTITION BY RANGE COLUMNS (col_name)
INTERVAL interval [AUTO]
(
  PARTITION partition_name VALUES LESS THAN (value)
  [, PARTITION partition_name VALUES LESS THAN (value) ... ]
)

where

- col_name is the name of one column of type DATE or DATETIME or
  TIMESTAMP
- at least one partition is supplied
- INTERVAL interval is a time interval

When performing DML on such a table, it will first add partitions
by the specified interval until the partition covers the current time.

Partition addition will not cause an implicit commit like DDL normally
does.

The partitions are named pN.

Otherwise the table behaves exactly the same as a normal RANGE COLUMNS
partitioned table.

Note that TIMESTAMP is not allowed as a type for PARTITION BY RANGE
COLUMNS otherwise.
9f98f82b14a9...
9f98f82b14a9b939834281672b6d0cf965db69a3
Oleksandr Byelkin
Merge branch '11.8' into 12.3
7f923870722c...
7f923870722c5d382e16d56af526d1ee4e03f987
Oleksandr Byelkin
Merge branch '12.3' into 13.0
7c8a25a2bba8...
7c8a25a2bba8bc559db34eb3068a8d53be75ca95
Dave Gosselin
MDEV-39746: Segmentation fault with FULL JOIN

When an 'inner' table of a FULL JOIN sat inside a nest that was
itself the left side of an enclosing FULL JOIN,
make_outerjoin_info skipped that embedding while building the
outer join scope chain and left the inner table's first_upper
unlinked.  When make_join_select later pushed an ON condition to
that table, add_found_match_trig_cond walked off the broken
chain and dereferenced NULL.

Fix make_outerjoin_info to set first_upper for a tab that
carries its own outer join scope (first_inner == tab) when its
immediate embedding did not link it.  Point first_upper at the
nested_join->first_nested of the first enclosing outer join nest
the embedding walk reaches.

The same query exposed a second bug.  The outermost FULL JOIN's right
operand was a nested join rather than a single base table.  The parser
places the nest on the right when the outermost FULL JOIN's ON is the
last one written, because the parser keeps the outermost FULL JOIN
pending until its ON arrives, and the inner FULL JOINs reduce first
into a nest that becomes the right operand.
alloc_full_join_duplicate_filters allocates the fj_dups filter on a
JOIN_TAB carrying JOIN_TYPE_FULL | JOIN_TYPE_RIGHT, so with the
FULL|RIGHT bits on the nest, which is never a JOIN_TAB, no filter was
allocated and the null complement pass never fired.  The unmatched
rows from the right side were never emitted, producing a result with
fewer rows than the SQL:2016 standard requires.

Add swap_full_join_sides, called from rewrite_full_outer_joins
when a FULL JOIN survives simplify_joins with a leaf on the left
and a nested join on the right.  FULL JOIN is symmetric on its
operands, so swapping does not change query semantics; after the
swap the leaf carries the FULL|RIGHT bits and the rescan target
is a single base table.
75640266ecb4...
75640266ecb456168c5b3945e6c733bb693cc9f2
Georg Richter
bump the version to 3.3.20
72bfac82a94d...
72bfac82a94d59b4a7b2e82270516d55f6c6a485
Mohammad Tafzeel Shams
MDEV-38305: Expose adaptive hash index statistics in ANALYZE FORMAT=JSON

Expose InnoDB's Adaptive Hash Index (AHI) statistics through ANALYZE
FORMAT=JSON output to provide query-level visibility into AHI usage
and effectiveness. This allows DBAs and developers to monitor how well
the adaptive hash index is serving their workloads on a per-query basis.

The r_ahi_stats object (nested inside r_engine_stats) now reports four
key metrics: ahi_searches (successful AHI lookups), ahi_searches_btree
(AHI misses requiring B-tree fallback), ahi_rows_added (rows inserted
into AHI), and ahi_pages_added (pages indexed by AHI).

- btr_ahi_inc_searches(): Increment counter when AHI lookup succeeds.
- btr_ahi_inc_searches_btree(): Increment counter when AHI lookup fails
  and falls back to B-tree search.
- btr_ahi_inc_rows_added(): Increment counter when rows are added to
  the adaptive hash index structure.
- btr_ahi_inc_pages_added(): Increment counter when new pages are
  indexed by AHI.
- btr_cur_t::search_leaf(): Call btr_ahi_inc_searches() on successful
  AHI hit and btr_ahi_inc_searches_btree() on AHI miss to track search
  outcomes at the point where AHI is utilized.
- trace_engine_stats(): Output r_ahi_stats object with all four AHI
  counters in JSON format when any AHI activity is detected during query
  execution.
- ha_handler_stats: Added ahi_searches, ahi_searches_btree, ahi_rows_added,
  and ahi_pages_added fields to track per-query AHI statistics.
- ahi_stats.test: Comprehensive verification of AHI statistics reporting
  across different scenarios: insufficient accesses (no AHI build),
  threshold triggering (AHI construction), heavy warmup (full AHI
  utilization), and disabled AHI (verify zero statistics).
- check_ahi_status.inc: Reusable include file for executing queries with
  configurable warmup repetitions and extracting AHI statistics from
  ANALYZE FORMAT=JSON output using JSON path expressions.
6ffb3354b325...
6ffb3354b32598fadff7333794b235edbabd8a6c
Georg Richter
bump the version to 3.4.10
  • cc-x-codbc-windows: 'dojob pwd if '3.4' == '3.4' ls win32/test SET TEST_DSN=master SET TEST_DRIVER=master SET TEST_PORT=3306 SET TEST_SCHEMA=odbcmaster if '3.4' == '3.4' cd win32/test if '3.4' == '3.4' ctest --output-on-failure' failed -  stdio
6bc94e0e2ef9...
6bc94e0e2ef92511235b9cc9659a57e0814e38c8
Marko Mäkelä
MDEV-39344 trx_disconnect_prepared() uses wrong mutex

trx_t::disconnect_prepared(): Replaces trx_disconnect_prepared().
Protect is_recovered, mysql_thd with mutex, to be consistent with
protecting fetch_data_into_cache_low().

This fixes up
commit c0817dac99c28698dfc2b548d89acf1fb41dc32e (MDEV-29575).

Suggested by: Sergey Vojtovich
6b35f1748d64...
6b35f1748d64858d21fc1ca76976bd56483d5c63
Sergei Golubchik
Merge branch '11.4' into 11.8
6b2faac79c18...
6b2faac79c18b9804d3d0244f1a3a822fad137a9
Alexander Barkov
MDEV-39518 Allow prepared statements in stored functions in assignment right hand

In progress
5f8d9cceb329...
5f8d9cceb329251a4a61b089a270840b9669209b
Vladislav Vaintroub
update appveyor config

Go back to clone_depth=1.
With the increased amount of pushes, testing old commits only increases
queue
5a9af15a2ca7...
5a9af15a2ca712c8d35756385618125fb37522be
Bill Jin
MDEV-39548 Cleanup MDL_request boilerplate with ACQUIRE_LOCK macro

Add new acquire_lock() overloads on MDL_context that combine MDL_request
initialization and lock acquisition into a single call, returning
MDL_ticket* directly. Convert applicable call sites across the codebase
to use the new ACQUIRE_LOCK macro.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
539562892eb1...
539562892eb1aaba003859d313be86bf43cf0a6d
Marko Mäkelä
MDEV-39344: fetch_data_into_cache() clears "is_truncated"

There is a memory limit implemented for the INFORMATION_SCHEMA tables
innodb_trx, innodb_locks, innodb_lock_waits. The predicate
trx_i_s_cache_is_truncated() would never hold in
trx_i_s_common_fill_table() due to a logic bug that had been
introduced in a refactoring.

fetch_data_into_cache(): Shrink the critical section of lock_sys.latch
and do not unconditionally reset cache->is_truncated when leaving the
function. This fixes a correctness regression that had been introduced
in commit 02270b44d07b78336e0f0d6afe9934587281e056 (MDEV-14756).
4cce5bf1bafd...
4cce5bf1bafd4fbffe64d040d68734a9e4400789
Rex Johnston
MDEV-39495 Parallel Query: Use temporary work tables to ship results: basic test

Built on top of MDEV-39492, the parallel worker manager creates N
temporary tables and gives them to each parallel worker to populate.
At the conclusion of all worker threads, each row from the above tables
is added to the join_tab->table representing the query result.  To use

MariaDB [test]> set session parallel_worker_threads=10;
Query OK, 0 rows affected (0.001 sec)

MariaDB [test]> select SQL_BUFFER_RESULT * from t1;
+-------+------+
| a    | b    |
+-------+------+
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
| 12345 | test |
|    1 | one  |
|    2 | two  |
|    1 | un  |
+-------+------+
13 rows in set (1.989 sec)

rows where a=12345 are added by the parallel workers, otherwise
they are from t1;
491e9d031cdb...
491e9d031cdbc0b45f4c4567f079d1c083b11683
Daniel Black
Bump columnstore to a8d54707968ed9f00e774a7f8de2adb31c9a0174 (RHEL9+selinux)
46a8eb42a520...
46a8eb42a520193686d9a16d4cea4b3e002917e4
Sergei Golubchik
fix plugins.feedback_os_release failure on sles-1600

just the comment at the beginning of its /etc/os-release
is already more than 256 bytes
3e5326001e5d...
3e5326001e5dcc1adb9770c6c312d5ccc6fb8863
Yuchen Pei
MDEV-15621 Auto add RANGE COLUMNS partitions by interval

Allow auto partitioning by interval in PARTITION BY RANGE COLUMNS

PARTITION BY RANGE COLUMNS (col_name)
INTERVAL interval [AUTO]
(
  PARTITION partition_name VALUES LESS THAN (value)
  [, PARTITION partition_name VALUES LESS THAN (value) ... ]
)

where

- col_name is the name of one column of type DATE or DATETIME or
  TIMESTAMP

- at least one partition is supplied, and the highest partition cannot
  have MAXVALUE range

- INTERVAL interval is a positive time interval. it can be mariadb
  format or oracle NUMTODSINTERVAL/NUMTOYMINTERVAL format. Like
  versioning, the smallest unit is second, i.e. no subsecond like
  microsecond.

- DATE column cannot have interval with values less than a day

When performing DML on such a table, it will first add partitions
by the specified interval until the partition covers the current time.

Partition addition will not cause an implicit commit like DDL normally
does.

The partitions are named pN.

Otherwise the table behaves exactly the same as a normal RANGE COLUMNS
partitioned table.

Note that TIMESTAMP is not allowed as a type for PARTITION BY RANGE
COLUMNS otherwise.
3ca859c6200d...
3ca859c6200df96ff3268b8ed722cf0489cf073f
Georg Richter
Merge pull request #301 from heitbaum/patch-1

[CONC-805] fix assignment discards 'const' qualifier
38ab0d0885be...
38ab0d0885bec6aa9167a3ffd2ad5927dae23c70
Hemant Dangi
MDEV-38843: BF applier failed on a node causing complete Cluster lockup

Issue:
If a wsrep applier's run_applier() returned with anything other than
wsrep::provider::success while the server was not already shutting
down, the apply state machine was broken but the node stayed Primary
and kept receiving write sets it could not apply — silently locking
the cluster.

Solution:
wsrep_replication_process() now treats any non-success return as an
unexpected exit, logs a WSREP_ERROR, and calls
Wsrep_server_state::disconnect() so the cluster stops shipping write
sets to this node. Operator restarts to rejoin via IST/SST.
Operator-initiated wsrep_slave_threads shrink returns success and is
unaffected.
323644c5912a...
323644c5912a49d798719472594826d0e540f006
Vladislav Vaintroub
MDEV-39719 Fix memory allocation errors on Windows ARM64 CI

Do not overload the machine. Huge reservation seem to stress
Windows on ARM64 memory management, so that random OOM can appear
when multiple processes are constantly allocating/deallocating
huge chunks of memory. Thus, reduce number of parallel threads to 2,
and do not run replication tests.
197f92bee02d...
197f92bee02d8e836f529f37625be69b83e7acbd
Sergei Golubchik
Merge branch '10.6' into 10.11
14f4a0c96da9...
14f4a0c96da947ba686fbc9707b855745eb65723
Vladislav Vaintroub
update appveyor config

- Use VS2026 instead of VS2022
- do not try to checkout or build outdated (non-top of the branch)
  commits anymore, go back to clone_depth=1.
  With the increased amount of pushes, building old commits only increases
  queue on CI
05a2ff189f2a...
05a2ff189f2ab2ce33a29e923ee2cb1e96434ce6
Thirunarayanan Balathandayuthapani
MDEV-34358  Encryption threads consume CPU and deadlock with DROP TABLE/purge

Problem:
========
1. Encryption threads busy-wait when no work is available:

When reaching fil_system.space_list.end(), fil_crypt_return_iops() is called
with wake=true, causing pthread_cond_broadcast() to wake all threads
unnecessarily, leading to CPU waste.

2. Tablespaces with CLOSING/STOPPING flags skipped during iteration:

Since DDL completion doesn't wake encryption threads, these spaces may never
be encrypted if threads sleep indefinitely.

3. For default_encrypt_list iteration, when spaces exist but none are
acquirable, threads need to wake others for cooperative retry, but this
case was not distinguished from fil_system.space_list.end().

4. IOPS are allocated before searching for tablespaces, wasting resources
during iteration when no I/O occurs.

5. Encryption threads use fil_crypt_threads_cond for two different purposes:
waiting for encryption work and waiting for IOPS allocation. When
fil_crypt_return_iops() or fil_crypt_realloc_iops() broadcasts after
releasing IOPS, it wakes ALL threads including those correctly waiting
for work, causing spurious wakeups and CPU waste.

6. When innodb_encrypt_tables or innodb_encryption_rotate_key_age is changed
during encryption thread iteration, threads continue with stale configuration
values, potentially missing tablespaces that should be encrypted or rotated
under the new settings.

7. The InnoDB encryption thread could deadlock with DROP TABLE and purge
operations in a three-way deadlock scenario:

- DROP TABLE thread holds lock_sys.latch and waits for the tablespace
pending reference count to reach zero before dropping the space.

- Encryption thread holds a tablespace reference and waits to acquire
the tablespace allocation latch in exclusive mode to call
fseg_page_is_allocated() for checking if a page is allocated before
encrypting it.

- Purge coordinator thread holds the tablespace allocation latch
in exclusive mode and waits to acquire lock_sys.latch
in shared mode for record lock operations.

This creates a circular dependency and leads to deadlock.

Solution:
=========
1. Implement timed wait with exponential backoff:

When space == fil_system.space_list.end() (applies to both default_encrypt_list
and space_list iteration when no acquirable spaces are found):
- First timeout: 5 seconds
- Subsequent timeouts: (timed_wait_count + 1) * 5 seconds (10s, 20s, 40s, 60s)
- After 5 consecutive timeouts (~135 seconds total), continue with 60-second
timed waits to ensure threads periodically recheck for state changes
- Timeout counter resets to 0 when woken by signal or when work is found

2. Move IOPS allocation from before tablespace search to after finding a space
that needs rotation. If allocation fails, set recheck=true to skip waiting
and immediately try next space.

Encryption threads would hold space references while waiting in
fil_crypt_alloc_iops(), blocking DROP TABLE. To prevent this,
encyption should do release-wait-reacquire pattern.

fil_crypt_alloc_iops(): Added nowait parameter (default false). When
nowait=true, returns immediately if IOPS not available instead of waiting.

fil_crypt_thread(): Try non-blocking IOPS allocation first with nowait=true.
Only if IOPS not immediately available:
- Save space ID and release space reference
- Wait for IOPS with nowait=false
- Reacquire space using fil_space_get_by_id() and space->acquire()
- If space dropped or stopping, release IOPS and skip

This ensures encryption threads never hold space references while waiting
for IOPS, allowing DROP TABLE operations to proceed without deadlock.

3. Introduce separate condition variable fil_crypt_iops_cond specifically for
IOPS allocation synchronization to prevent spurious wakeups:

- fil_crypt_threads_cond: Used in wait_for_work() for waiting when no
tablespaces need encryption. Signaled when settings change, new
tablespaces are created, or thread count changes.

- fil_crypt_iops_cond: Used in fil_crypt_alloc_iops() for waiting
when IOPS limit is reached. Signaled when IOPS are returned via
fil_crypt_return_iops(), released via fil_crypt_realloc_iops(), or
when srv_n_fil_crypt_iops is increased.

4. Added atomic version counter fil_crypt_settings_version that is incremented
whenever innodb_encrypt_tables or innodb_encryption_rotate_key_age changes.
Encryption threads capture the version at iteration start and check for
changes during iteration. If config changed, threads immediately restart
iteration from the beginning to ensure complete coverage with new settings.

New fields:
- fil_crypt_settings_version: Atomic counter to track configuration changes
- rotate_thread_t::timed_wait_count (uint8_t): Counts consecutive timeouts
  for exponential backoff
- rotate_thread_t::wait_for_work(): Implements timed/indefinite wait strategy
- rotate_thread_t::settings_version: Compares with fil_crypt_settings_version
  to restart encryption from the beginning

5. Fix three-way deadlock with trylock mechanism:
fseg_page_is_allocated(): Added optional caller_mtr parameter. Encryption
thread passes an mtr, allocation bitmap page latch is now correctly held
in that mtr until the caller commits it.

fil_crypt_get_page_throttle(): Use fil_space_t::x_lock_try() to acquire
the tablespace allocation latch non-blockingly. If the trylock fails,
back off and retry the same page to avoid deadlock. The bitmap page
S-latch is added to the mtr and held throughout the page read and
encryption operations. Release the tablespace exclusive latch immediately
after the allocation check to minimize contention, while the bitmap page
S-latch remains held in the mtr.

fil_crypt_rotate_page(): After 10 retries on page latch acquisition,
release IOPS, sleep 10ms, then try to reacquire IOPS with nowait=true.
If IOPS not immediately available, exit gracefully by setting first=true.
This periodic IOPS release allows other encryption threads working on
tablespaces being dropped to make progress and release their space
references, helping to break the deadlock scenario.
04b46a0aec2a...
04b46a0aec2a4545b1603d9e113fede94157c4c2
Alexander Barkov
MDEV-39518 Allow prepared statements in stored functions in assignment right hand

In progress
BuildBot (0.8.9) working for the MariaDB project.
Page built: Wed 27 May 2026 09:14:03 (UTC)