-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Btree, Transactions
-
Security Level: Public (Available to anyone on the web)
-
Storage Engines - Transactions
-
2,392.315
-
SE Transactions - 2026-03-13, SE Transactions - 2026-04-24
-
8
When a standby steps up, it needs to copy the content from the stable table to the ingest table. If a key has been prepared (either committed or rolled back now) and the prepared timestamp is stable but the durable timestamp or rollback timestamp is not stable, we must have written a prepared update to the stable table. In this case, during the draining process, we need to resolve this prepared update on the stable table. Otherwise, we will have a prepared update never resolved on the stable table.
This ticket aims to implement this logic based on the work done in WT-16743.
- is related to
-
-
- Closed
-
-
WT-17242 44.35% increase in Latency read(in micro sec) Max2 in Variant ubuntu2004-perf-tests for Task many-dhandle-stress in Test many-dhandle-stress.py
-
- Backlog
-
- related to
-
-
- Blocked
-