| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
The Galera tests were massively failing with debug assertions.
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
|
| | |
| |
| |
| |
| |
| | |
Other things:
- Handler errors from ha_maria::implict_commit
- Disable DBUG in safe_mutex_lock to get trace file easier to read
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| | |
Redo changes reverted in commit
8f46e3833c7acb3ec3e4c7b389ae8cdd98eff1ce, this time without build
issues in wsrep-lib.
|
| | |
| |
| |
| |
| | |
This reverts commit 2b5f4b3ed68585b310b7ebede474928ff90d9aa2
due to build failures.
|
| | |
| |
| | |
Update wsrep-lib, and adapt to wsrep-lib interface changes.
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
MariaDB 10.4 was crashing when thread-handling was set to
pool-of-threads and wsrep was enabled.
There were two apparent reasons for the crash:
- Connection handling in threadpool_common.cc was missing calls to
control wsrep client state.
- Thread specific storage which contains thread variables (THR_KEY_mysys)
was not handled appropriately by wsrep patch when pool-of-threads
was configured.
This patch addresses the above issues in the following way:
- Wsrep client state open/close was moved in thd_prepare_connection() and
end_connection() to have common handling for one-thread-per-connection
and pool-of-threads.
- Thread local storage handling in wsrep patch was reworked by introducing
set of wsrep_xxx_threadvars() calls which replace calls to
THD store_globals()/reset_globals() and deal with thread handling
specifics internally.
Wsrep-lib was updated to version which relaxes internal concurrency
related sanity checks.
Rollback code from wsrep_rollback_process() was extracted to separate calls
for better readability.
Post rollback thread was removed as it was completely unused.
|
| |/
|
|
|
|
| |
* Collect and pass apply error data to provider
* Rollback failed transaction and continue operation if provider returns
SUCCESS
* MTR tests for inconsistency voting
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Changed replaying to always allocate a separate THD object
for applying log events. This is to avoid tampering original
THD state during replay process.
- Return success from sp_instr_stmt::exec_core() if replaying
succeeds.
- Do not push warnings/errors into diagnostics area if the
transaction must be replayed. This is to avoid reporting
transient errors to the client.
Added two tests galera_sp_bf_abort, galera_sp_insert_parallel.
Wsrep-lib position updated.
|
| |
|
|
|
|
|
|
| |
Wsrep-lib is now guaranteed to hold the underlying mutex
which is wrapped in lock object passed to Wsrep_client_service
interrupted() call. The library part will now take care of
checking the wsrep::transaction specific state, so it is
enough to check the thd->killed state for the result.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The replayer did not signal replaying waiters. Added
mysql_cond_broadcast() after replaying is over.
Assertion on client error failed after replay attempt failed due
to certification failure. At this point the transaction does not
go through client state, so the client error cannot be overridden.
Assign ER_LOCK_DEADLOCK to thd directly instead.
Use timed cond wait when waiting for replayers to finish and
check if the transaction has been BF aborted during the wait.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that the Annotate_rows_log_events is written into
binlog only for the first fragment of the current statement.
Also avoid flusing pending rows event when calculating bytes
generated by the transaction.
Added and recorded a test which verifies that the binlog
contains only one Annotate_rows_log_event per statement
with various SR settings. Recrded mysql-wsrep-features#136
which produced different output with excession log events
suppressed.
|
| |
|
