Summary
Eviction cache stuck unnecessarily rollbacks the transactions that are not blocking the eviction.

Whenever eviction is not able to progress, it checks for any older transactions that are blocking the eviction and rollbacks them to avoid cache being stuck in __wt_txn_is_blocking function. This function rollbacks the current session that is performing the eviction is the oldest transaction in the system or the snapshot pinned transaction is the oldest transaction.

    /*
     * Check if either the transaction's ID or its pinned ID is equal to the oldest transaction ID.
     */
    return (txn_shared->id == global_oldest || txn_shared->pinned_id == global_oldest ?
        __wt_txn_rollback_required(session, WT_TXN_ROLLBACK_REASON_OLDEST_FOR_EVICTION) :
        0);

This process of rolling back the transaction with a snapshot of pinned transaction that has the oldest id doesn't avoid the cache stuck as these transactions can be new and all the newer transactions can have the oldest id as the pinned transaction.

Motivation

• Does this affect any team outside of WT?
  • No.

• How likely is it that this use case or problem will occur?
  • More likely whenever a long-running transaction is running in the system.

• If the problem does occur, what are the consequences and how severe are they?
  • Unnecessary transaction rollback needs to re-run the transaction.

• Is this issue urgent?
  No

Solution:

• I don't have any proper solution to avoid the unnecessary transaction rollback operations that don't avoid the cache stuck. I agree with the condition of checking the pinned_id.