Rounding up the read timestamp

Applications setting timestamps for a transaction have to comply with the constraints based on the global timestamp state. In order to be compliant with the constraints, applications will need to query the global timestamp state, check their timestamps for compliance, and adjust timestamps if required. To reduce application burden, WiredTiger supports automatic timestamp rounding in some scenarios.

Applications can configure roundup_timestamps=(read=true) with the WT_SESSION::begin_transaction method. Configuring roundup_timestamps=(read=true) causes the read timestamp to be rounded up to the oldest timestamp. If the read timestamp is greater than the oldest timestamp no change will be made.

Using rollback-to-stable with timestamps

Applications can explicitly roll back the system to a specific stable timestamp by calling the WT_CONNECTION::rollback_to_stable method. Applications must first set the stable timestamp using WT_CONNECTION::set_timestamp and then call WT_CONNECTION::rollback_to_stable, which will discard all updates to checkpoint-durable tables that have commit timestamps more recent than the set stable timestamp.

Logged tables and updates made without an associated commit timestamp are unaffected.

The database must be quiescent during this process, and applications must close or reset all open cursors before calling the WT_CONNECTION::rollback_to_stable method.

Using diagnostic configurations to enforce timestamp usage

The WT_SESSION::create method supports additional checking of timestamp usage on a per-table basis. While these usage checks can decrease application performance, and applications may not choose to configure them in production settings, they are strongly recommended during development.

By default, WiredTiger requires timestamps be used in "ordered" mode: updates to a table can be made either with and without a commit timestamp, but once a commit timestamp is used to update a key, all future updates to the key will require a commit timestamp. Further, each update to a key must have a commit timestamp at or after any previous update.

Setting the write_timestamp_usage configuration changes how timestamps are expected to be used in the table:

Configuration	Description
never	Require no updates to the table have a commit timestamp.
mixed_mode	Allow updates both with and without a commit timestamp. Each update must have a commit timestamp at or after the previous update, or no timestamp at all.

The write_timestamp_usage configuration is expected to be used with the WT_SESSION::create method's assert configuration. The "assert(read_timestamp)" configuration requires timestamps always or never be used on reads in the table.

The "assert(write_timestamp)" configuration requires update timestamps conform to the write_timestamp_usage setting. If WiredTiger detects a violation of the configured policy, an error message will be logged. Additionally, in diagnostic builds, the library will fail and drop core at the failing check.

Warning: These are best-effort checks by WiredTiger, and there are cases where application misbehavior will not be detected.

In-memory configurations and timestamps

Timestamps are supported for in-memory databases, but must be configured as in ordinary databases, and the same APIs are used in both cases for historical reasons. By default, in-memory database objects behave like commit-level objects in ordinary databases, that is, timestamps are ignored. If logging is disabled for the object, using the "log=(enabled=false)" configuration, then the timestamps will not be ignored and will behave as with objects in ordinary databases where logging has been disabled.