Details
Description
Given a large enough page is created a by a transaction running in WiredTiger, it may get force evicted causing a rollback to be returned to the transaction, the transaction also needs to be the oldest transaction in the system and meet the criteria to be "blocking", see: __wt_txn_is_blocking. However this behaviour is also impacting MongoDB transactions.
The original change WT-6444 was intended to rollback batch operations and have the mongodb layer split them into smaller chunks, as a consequence of this change we are rolling back more than we intended.
There are two possible fixes here:
- Improve the heuristic used to determine whether we should roll back a transaction.
- Have MongoDB supply a config to WiredTiger to identify that a MongoDB transaction is running, and skip the rollback logic.
I've created a python reproducer for this scenario:
import time, wiredtiger, wttest
|
from wtscenario import make_scenarios
|
|
def timestamp_str(t):
|
return '%x' % t
|
|
class test_repro01(wttest.WiredTigerTestCase):
|
conn_config = 'cache_size=10000MB,eviction=(threads_max=1)'
|
session_config = 'isolation=snapshot'
|
|
def test_repro01(self):
|
uri = 'table:test_repro01'
|
self.session.create(uri, 'key_format=i,value_format=S')
|
self.conn.set_timestamp('oldest_timestamp=' + timestamp_str(1))
|
cursor = self.session.open_cursor(uri)
|
doc_count = 30000
|
value1 = 'x' * 1000
|
for j in range(0, 9):
|
self.session.begin_transaction()
|
for i in range(j*doc_count, (j+1)*doc_count):
|
cursor[i] = value1
|
self.session.commit_transaction('commit_timestamp=' + timestamp_str(2))
|
|
Â
Â
Attachments
Issue Links
- is related to
-
SERVER-53464 Transaction with many documents working on MongoDB 4.2 but not 4.4
-
- Closed
-
-
WT-6444 Abort a transaction if it is force evicting and oldest
-
- Closed
-