[SERVER-38128] Create a periodic task associated with the KV engine to notify listeners of stable/oldest/checkpointed timestamp changes Created: 14/Nov/18  Updated: 29/Oct/23  Resolved: 12/Dec/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-59005 Storage engine clean shutdown can rac... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-12-03, Storage NYC 2018-12-17
Participants:

 Description   

This periodic task should only be registered to run if the storage engine supports timestamps.



 Comments   
Comment by Githook User [ 12/Dec/18 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-38128 Create a periodic task associated with the KV engine to notify listeners of stable/oldest/checkpointed timestamp changes
Branch: master
https://github.com/mongodb/mongo/commit/3504c48bd882975aed1ab933ed307fc755091487

Comment by Githook User [ 12/Dec/18 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-38128 Remove virtual functions in WiredTigerKVEngine and implement getCheckpointTimestamp()
Branch: master
https://github.com/mongodb/mongo/commit/d69c476974e76206260855c91d82c39296a40b8a

Comment by Githook User [ 12/Dec/18 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-38128 Add methods to access the storage engine's timestamps
Branch: master
https://github.com/mongodb/mongo/commit/3b6838d90094c7dc3e406e65c0fc2069f5b50725

Comment by Githook User [ 12/Dec/18 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-38128 Start periodic runner before the storage engine
Branch: master
https://github.com/mongodb/mongo/commit/17532dff912ceb6233cd8d7db8c1b47e4859ffaf

Comment by Andy Schwerin [ 14/Nov/18 ]

That makes sense. I think that as long as the system isn’t used to advertise timestamps that could roll back, asynchronous reporting would work

Comment by Dianna Hohensee (Inactive) [ 14/Nov/18 ]

The idea is that we have operations that need to wait for a certain timestamp to be reached before acting, in a lazy manner, which I think is alright but haven't thought out all the way. Storage wants it for things like two-phase collection and index drops. Once the timestamp of the first phase of a drop reaches some safe persistence guarantee, we trigger the second phase of the drop.

I'm not sure on the design yet. One of my thoughts was a periodic task, since we don't need an instant response, that updates some state about what the timestamps were at the last check and notifies any caller waiting on an update – say a shared condition variable or something akin to that. The design is up to this ticket to figure out.

Comment by Andy Schwerin [ 14/Nov/18 ]

Who are the listeners, and how frequently do they need to be notified?

Generated at Thu Feb 08 04:48:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.