Loading...

XML

Word

Printable

JSON

Type: Bug
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.3.4
Affects Version/s: None
Component/s: Replication
Labels:
None

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Sprint:
Repl 2020-02-10
Linked BF Score:
20
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

After ~~SERVER-39364~~, ReplClientInfo::setLastOpToSystemLastOpTime acquires a global IS lock and implicitly the RSTL lock in MODE IX. But when setLastOpToSystemLastOpTime is called on a retry of a prepared transaction, it breaks the contract that prepared transactions should not hold RSTL locks.

Updated: We dont have to call setLastOpToSystemLastOpTime, we can simply set client lastOp to max(prepareOpTime, lastAppliedOpTime)

is caused by

SERVER-39364 Audit uses of setLastOpToSystemLastOpTime

Closed

is duplicated by

SERVER-45598 Complete TODO listed in SERVER-39364

Closed

Assignee:: Lingzhi Deng
Reporter:: Lingzhi Deng
Participants:: Githook User, Lingzhi Deng
Votes:: 0 Vote for this issue
Watchers:: 5 Start watching this issue

Created:: Jan 27 2020 09:32:41 PM UTC
Updated:: Oct 29 2023 10:12:50 PM UTC
Resolved:: Jan 30 2020 05:19:33 AM UTC
Confidence Status Last Update:: 28/Jan/20 2:53 AM