There is a bug in MongoDB with reconstructing prepared transactions at startup (see SERVER-58409 for details). We discovered that the simplest solution would be to have MongoDB use a read timestamp equal to the prepare timestamp on startup to ensure that the first write into the RecordStore does not re-use a RecordId for a deleted record.
The proposed MongoDB change exercises the following assertion: "prepare timestamp X must be greater than the latest active read timestamp Y".
The simplest solution we can think of is to bypass this assertion. daniel.gottlieb proposed a behavior change that would allow the configuration "roundup_timestamps=(prepared=true)" to bypass this assertion. We already set this flag when recovering prepared transactions on startup.
- is depended on by
-
SERVER-58409 Startup RecordId initialization is flawed with durable history and reconstructing prepared transactions
- Closed
- is duplicated by
-
SERVER-59076 Support setting a prepare timestamp at current read timestamp
- Closed
- is related to
-
WT-7992 Provide API to return the last key in a table regardless of visibility
- Closed