[SERVER-65910] the server tests attempt to set illegal durable and oldest timestamps Created: 23/Apr/22 Updated: 26/Apr/22 Resolved: 26/Apr/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Keith Bostic (Inactive) | Assignee: | Keith Bostic (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
In WT-9042, the WT code to set the global timestamps was simplified, but also changed to eliminate possible races and to validate the final state of the timestamps. Running an MDB server build reported some errors. The MDB server build is here: There are complaints about setting the oldest timestamp after stable, here's an example from replica_sets_large_txns_format_2_enterprise-rhel-80-64-bit-dynamic-all-feature-flags-required, at: https://logkeeper.mongodb.org/build/3f81046
There are complaints about setting the durable timestamp before stable, here's an example from disk_wiredtiger, at: https://logkeeper.mongodb.org/build/ec4076fcbe010429d5ba553821902f95/test/62642f26be07c42af4119b16?raw=1
|
| Comments |
| Comment by Keith Bostic (Inactive) [ 25/Apr/22 ] |
|
Thanks, daniel.gottlieb@mongodb.com – yes, this one is mine for now. |
| Comment by Daniel Gottlieb (Inactive) [ 25/Apr/22 ] |
|
There are two states which cause the majority of failures:
Both states are capable of setting advanceTimestampsEachBatch which will advance the oldest timestamp as batches complete without advancing the stable timestamp. Those cases (I claim) are ultimately benign. We're only taking checkpoints with use_timestamp=false. The history preserved by the oldest timestamp is not needed for readers. And historical values are not needed for fuzzy checkpoints restoring a stable checkpoint. keith.bostic@mongodb.com and I talked offline about the relationships between the oldest vs stable timestamps and came up with a more precise set of assertions. Keith is going to run a follow-up patch to see if there's anything leftover which looks concerning (correct me if I'm wrong Keith!) |
| Comment by Keith Bostic (Inactive) [ 23/Apr/22 ] |
|
daniel.gottlieb@mongodb.com, geert.bosch@mongodb.com, I'm seeing unexpected results when I tighten down setting global timestamps, can I please ask for some server assistance here?
Dan, we could easily drop core if there's an attempt to set an illegal timestamp combination in HAVE_DIAGNOSTIC mode, just like we do when checking timestamps at commit time, if that would help with debugging. |