Summary

WiredTiger documentation states that the setting multiple commit timestamps feature “is not compatible with prepared transactions, which must use only a single commit timestamp.” However, is not currently enforced by WiredTiger. For example, it is possible to create a transaction with the following timestamps:

1. Begin transaction
2. Prepare transaction with prepare_timestamp = 10
3. Set the commit_timestamp = 20
4. Set the commit_timestamp = 15
5. Commit transaction with durable_timestamp = 30

It is currently up to the user to know that this is an invalid use of timestamps. We should make it more clear to the user if they violate this constraint.

Motivation

• Does this affect any team outside of WT?
  If we decide to tighten the timestamp API we need to discuss with the server team.
• How likely is it that this use case or problem will occur?
  It is possible to make a mistake with the usage of timestamps.
• Is this issue urgent?
  No.

Acceptance Criteria (Definition of Done)

• Testing
  There should be no fallout after adding stricter checks around setting multiple commit timestamps. We should extend timestamp tests or add new ones if we add warning messages or asserts.

• Documentation update
  If we decided not to tighten the constraints in wiredtiger the documentation should be more explicit about this scenario not enforcing the constraints.

[Optional] Suggested Solution
(Is there any suggested solution to handle this issue? Is it related to any existing WT ticket? Is it related to any previous issue fixed? If yes, link the WT ticket number using related to, depends on, dependent on by links)