Timestamp APIs (oldest/stable/pinned)
Parent: WiredTiger Storage Engine Internals · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-ae873d2f56e0
↓ Facts as markdownall context files
Source-anchored research for Timestamp APIs (oldest/stable/pinned). Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Measurements and reference values
- WiredTiger timestamps express application time, separate from internal transaction IDs. They are unsigned 64-bit values; API configuration strings encode them in hexadecimal without a leading 0x. (high confidence) [source]
Problems, failure modes and limitations
- Alibaba Cloud's MongoDB 4.0 source analysis independently connects slow oldest-timestamp advancement with excessive version retention and cache pressure. Its memory-residency details describe the 2018 implementation. (medium confidence) [source]
- WT-4715 documents a historical cache-stall investigation involving an eviction participant pinning old transaction state. Its reported reproducer explicitly disabled timestamps, so it does not establish a timestamp-specific failure. (low confidence) [source]
Comparisons and alternatives
- The development checkpoint guide describes checkpoint_timestamp as saved stable_timestamp metadata rather than the checkpoint transaction's read timestamp; startup recovery removes updates newer than that boundary. (low confidence) (verified as of 2026-10-23) [source]
- WiredTiger timestamps represent application time rather than necessarily wall-clock time. They operate alongside internal transaction IDs; timestamped reads must also satisfy snapshot visibility. (high confidence) [source]
- Percona's March 2023 recovery experiment records distinct recovery and oldest timestamps, and checkpoint output carries oldest and checkpoint timestamps separately. These logs illustrate observable boundaries rather than a single database timestamp. (low confidence) [source]
Facts and statements
- oldest_timestamp declares the earliest timestamp for future reads. Advancing it permits discarding earlier history, but existing readers at earlier timestamps remain protected. (high confidence) [source]
- query_timestamp(get=pinned) reports the minimum of oldest_timestamp and active reader timestamps, including a running checkpoint. It is read-only and can lag oldest_timestamp. (high confidence) [source]
- Applications manage oldest_timestamp and stable_timestamp through WT_CONNECTION::set_timestamp. Normally oldest must not exceed stable, and neither moves backward; forcing backward movement can expose incomplete history and inconsistent results. (high confidence) [source]
- Advancing stable_timestamp alone neither starts a checkpoint nor changes data durability. The newly eligible updates become recoverable through a subsequent checkpoint. (high confidence) [source]
- In their 2022 WiredTiger protocol model, Ouyang et al. make an update visible only if it passes transaction-ID snapshot checks and has a non-null timestamp no later than the transaction's read timestamp; the model encodes both tests in one visibility predicate. (high confidence) [source]
- roundup_timestamps=(read=true) on WT_SESSION::begin_transaction raises a requested read timestamp below oldest to oldest; it leaves a later read timestamp unchanged. (high confidence) [source]
- The 11.0 timestamp guide scopes rollback_to_stable to checkpoint-durable data: logged tables and untimestamped updates are unaffected. It requires resolved transactions, reset or closed cursors, and no concurrent API calls. (high confidence) [source]
- query_timestamp exposes oldest_reader, last_checkpoint, and recovery separately from oldest_timestamp and pinned. These distinguish active-reader retention, the last checkpoint boundary, and the boundary recovered at startup. (low confidence) [source]
- WT_CONNECTION::set_timestamp sets oldest_timestamp and stable_timestamp. WT_CONNECTION::query_timestamp retrieves global state using selectors such as get=pinned, get=oldest_timestamp, get=stable_timestamp, and get=oldest_reader; pinned is read-only. (high confidence) [source]
- For checkpoint-durable tables, stable_timestamp bounds the updates included in timestamped checkpoints. The saved checkpoint timestamp supplies the recovery boundary; use_timestamp=false explicitly overrides timestamp filtering. (high confidence) [source]
- Failing to advance oldest and stable as writes accumulate can retain history and increase cache pressure. Alibaba Cloud's MongoDB 4.0 explanation independently emphasizes timely advancement of both boundaries. (high confidence) [source]
Children
- No children recorded.