ee17c7934c
wsrep_sync_wait is a per-statement-type bitmask (READ, UPDATE/DELETE, INSERT/REPLACE, SHOW) that forces a causal wait - block until this node has applied every write already certified cluster-wide - before executing a matching statement. wsrep_must_sync_wait() unconditionally skipped this wait whenever the session was already inside a multi-statement transaction, regardless of which bit was configured for the statement at hand. Once BEGIN (or, via autocommit=0, the first statement) had opened a transaction, every later statement in it was exempt from its own causal wait - so writes could run against a view no fresher than whatever BEGIN itself happened to check, which is only the READ bit, regardless of the actual configured mask. Fix: only skip the wait once this transaction has generated its first write (wsrep_has_changes(thd)). Every statement up to and including that first write is still safe to wait for - nothing of this transaction's is locked yet when the pre-statement check runs - which closes the gap above. Nothing after the first write re-waits, matching the original behaviour for the rest of the transaction: once this session may be holding row locks, a fresh causal wait risks a self-deadlock against its own local applier (which can be blocked needing one of those same locks to apply a write-set this wait is waiting for, with nothing to resolve it but the wait's own timeout). A second, independent defect surfaced once in-transaction waits could time out at all: wsrep::client_state::after_command_after_result() only clears a pending wsrep error once the transaction is no longer active - correct for a genuinely doomed BF-aborted transaction, but a causal-wait timeout is a pre-check failure that touches nothing, so this left every later statement in the same transaction, ROLLBACK included, failing with the same stale error. wsrep_sync_wait() now resets the error immediately after reporting it for the one statement that actually hit it, scoped to this failure path only - genuine BF-abort/deadlock errors elsewhere keep their correct sticky-until- rollback behaviour. Tests: galera_MDEV-38999.test covers the original bitmask gap across both explicit BEGIN and autocommit=0 transactions, and a repeated-read scenario proving a satisfied bit isn't cached across statements. galera_MDEV-38999_locks.test and galera_MDEV-38999_autocommit.test exercise the self-deadlock risk directly: a transaction already holding a row lock the paused applier needs must still return promptly once the applier is released, not block for the full repl.causal_read_timeout. Assisted-by Claude AI
Code status:
ci.appveyor.com
MariaDB: The innovative open source database
MariaDB was designed as a drop-in replacement of MySQL(R) with more features, new storage engines, fewer bugs, and better performance.
MariaDB is brought to you by the MariaDB Foundation and the MariaDB Corporation. Please read the CREDITS file for details about the MariaDB Foundation, and who is developing MariaDB.
MariaDB is developed by many of the original developers of MySQL who now work for the MariaDB Corporation, the MariaDB Foundation and by many people in the community.
MySQL, which is the base of MariaDB, is a product and trademark of Oracle Corporation, Inc. For a list of developers and other contributors, see the Credits appendix. You can also run 'SHOW authors' to get a list of active contributors.
A description of the MariaDB project and a manual can be found at:
https://mariadb.com/docs/release-notes
Getting the code, building it and testing it
Refer to the following guide: https://mariadb.org/get-involved/getting-started-for-developers/get-code-build-test/ which outlines how to build the source code correctly and run the MariaDB testing framework, as well as which branch to target for your contributions.
Help
More help is available from the Maria Discuss mailing list https://lists.mariadb.org/postorius/lists/discuss.lists.mariadb.org/ and MariaDB's Zulip instance, https://mariadb.zulipchat.com/
Licensing
MariaDB is specifically available only under version 2 of the GNU General Public License (GPLv2). (I.e. Without the "any later version" clause.) This is inherited from MySQL. Please see the README file in the MySQL distribution for more information.
License information can be found in the COPYING file. Third party license information can be found in the THIRDPARTY file.
Bug Reports
Bug and/or error reports regarding MariaDB should be submitted at: https://jira.mariadb.org
For reporting security vulnerabilities see: https://mariadb.org/about/security-policy/
The code for MariaDB, including all revision history, can be found at: https://github.com/MariaDB/server