1
0
mirror of https://github.com/MariaDB/server.git synced 2026-10-23 18:49:29 +03:00
Files
Pekka Lampio ee17c7934c MDEV-38999: Galera - stale reads in explicit transactions
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
2026-10-23 10:42:39 +03:00
..
…
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
…
2025-09-04 18:08:39 +03:00
2024-01-17 13:35:05 +02:00
…
…
…
2024-11-29 13:43:17 +02:00
2024-11-29 12:37:46 +02:00
2024-10-29 15:24:38 +01:00
…
2025-09-04 18:08:39 +03:00
2023-12-17 11:20:43 +01:00
…
…
…
2025-02-27 04:02:33 +01:00
2025-09-04 18:08:39 +03:00
2024-11-29 13:43:17 +02:00
…
…
2024-11-29 13:43:17 +02:00
2024-12-05 10:11:58 +01:00
2026-08-19 08:13:54 +02:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-01-28 14:22:20 +01:00
2026-07-23 11:12:27 +02:00
2026-01-28 14:22:20 +01:00
2024-11-29 13:43:17 +02:00
2023-11-08 16:23:30 +01:00
…
2024-06-27 10:26:09 +03:00
2024-06-24 13:09:47 +03:00
…
…
2025-09-04 18:08:39 +03:00
…
2023-11-08 16:23:30 +01:00
2026-10-20 18:58:35 +02:00
2023-10-14 13:36:11 +03:00
2026-01-28 14:22:20 +01:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2026-04-20 11:07:30 +03:00
2023-12-18 11:19:04 +01:00
2024-11-29 12:37:46 +02:00
…
2024-06-24 13:09:47 +03:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-07-22 15:14:50 +02:00
2026-06-15 10:43:23 +02:00
2026-06-15 10:43:23 +02:00
2025-10-28 17:49:51 +01:00
2025-10-28 17:49:51 +01:00
2026-07-23 11:12:27 +02:00
2024-11-29 12:37:46 +02:00
2026-08-19 08:13:54 +02:00
2025-09-04 18:08:39 +03:00
2025-01-10 13:14:42 +01:00
2024-06-24 13:09:47 +03:00
2025-01-30 11:55:13 +01:00
2025-01-30 11:55:13 +01:00
2023-07-10 11:22:21 +03:00
2024-11-29 13:43:17 +02:00
2024-11-29 13:43:17 +02:00
2026-08-19 08:13:54 +02:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-11-23 08:14:22 -07:00
2026-01-02 11:06:05 +02:00
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
2026-03-17 18:57:42 +01:00
2026-01-28 14:22:20 +01:00
…
2024-08-20 10:00:39 +02:00
2025-09-04 18:08:39 +03:00
2024-06-27 10:26:09 +03:00
2024-11-29 12:37:46 +02:00
…
2025-09-19 12:31:14 +03:00
2025-09-04 18:08:39 +03:00
2023-05-23 12:25:39 +03:00
2024-06-11 12:50:10 +03:00
2024-04-15 18:54:30 +02:00
2026-01-28 14:22:20 +01:00
2024-07-03 12:45:30 +02:00
2023-08-04 08:01:06 +02:00
2026-07-23 11:12:27 +02:00
2023-12-17 11:20:43 +01:00
2026-07-23 11:12:27 +02:00
2023-12-02 01:02:50 +01:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2026-03-17 11:05:34 +02:00
2024-03-27 15:00:56 +02:00
2025-09-04 18:08:39 +03:00
2025-01-20 09:57:37 +02:00
2025-03-27 08:01:47 +02:00
2023-09-25 13:06:57 +10:00
2024-01-18 19:22:23 +02:00
2023-08-01 15:08:52 +02:00
2024-11-23 08:14:22 -07:00
2024-11-23 08:14:23 -07:00
2026-08-19 08:13:54 +02:00
2026-07-23 11:12:27 +02:00
2024-01-10 18:01:46 +11:00
2025-09-04 18:08:39 +03:00
2025-09-04 18:08:39 +03:00
2024-06-24 13:09:47 +03:00
…
2025-09-04 18:08:39 +03:00
…
2024-11-29 13:43:17 +02:00
2024-01-02 17:37:58 +02:00
2024-06-27 10:26:09 +03:00
2026-06-21 15:32:20 +02:00
2024-01-03 15:37:57 +02:00
2024-10-03 10:55:08 +03:00
2026-07-23 11:12:27 +02:00
2026-07-23 11:12:27 +02:00
2026-06-21 15:32:20 +02:00