<!-- llms-explorer concept facts · https://llms-explorer.com/tree/timestamp-apis-oldest-stable-pinned/ · pack 2026-10-23 · ~1451 tokens -->

# Timestamp APIs (oldest/stable/pinned)

> Source-anchored research for Timestamp APIs (oldest/stable/pinned). Run status: COMPLETED.

Parent: [WiredTiger Storage Engine Internals](https://llms-explorer.com/tree/wiredtiger-storage-engine-internals/) · 4 facets · 17 facts · page: https://llms-explorer.com/tree/timestamp-apis-oldest-stable-pinned/

## 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](https://source.wiredtiger.com/mongodb-5.0/transactions.html)

## 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](https://alibaba-cloud.medium.com/multi-document-transactions-on-mongodb-4-0-eebd662ac237)
- 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](https://jira.mongodb.org/browse/WT-4715)

## 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](https://source.wiredtiger.com/develop/arch-checkpoint.html)
- 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](https://source.wiredtiger.com/11.2.0/arch-timestamp.html)
- 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](https://www.percona.com/blog/wiredtiger-logging-and-checkpoint-mechanism/)

## 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/11.2.0/arch-timestamp.html)
- 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](https://source.wiredtiger.com/11.0.0/timestamp_misc.html)
- 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](https://source.wiredtiger.com/11.0.0/timestamp_misc.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/develop/struct_w_t___c_o_n_n_e_c_t_i_o_n.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
- 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](https://source.wiredtiger.com/mongodb-6.0/timestamp_global_api.html)
