-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Engines
-
StorEng - Defined Pipeline
Currently at the end of commit/rollback transaction API there is a mechanism for the application thread to be pulled into eviction. Here for reference:
/*
* We're between transactions, if we need to block for eviction, it's a good time to do so.
* Ignore error returns, the return must reflect the fate of the transaction.
*/
if (!readonly)
WT_IGNORE_RET(__wt_evict_app_assist_worker_check(session, false, false, NULL));
return (0);
We purposely ignore the return value that gets created my application thread because the rollback/commit error needs to be reflected to the transaction state. However, there is ambiguity when an error occurs inside eviction that produces a message. For example:
/*
* If eviction is stuck, check if this thread is likely causing problems and should be
* rolled back. Ignore if in recovery, those transactions can't be rolled back.
*/
if (!F_ISSET(conn, WT_CONN_RECOVERING) && __wt_evict_cache_stuck(session)) {
ret = __wt_txn_is_blocking(session);
if (ret == WT_ROLLBACK) {
if (__wt_atomic_load32(&evict->evict_aggressive_score) > 0)
(void)__wt_atomic_subv32(&evict->evict_aggressive_score, 1);
WT_STAT_CONN_INCR(session, txn_rollback_oldest_pinned);
__wt_verbose_debug1(session, WT_VERB_TRANSACTION, "rollback reason: %s",
session->txn->rollback_reason);
}
WT_ERR(ret);
As of now, we produce an error message but the API itself returns back as successful.
This ticket aims to investigate in these cases as it can confuse users on whether an actual error happened or not.