[SERVER-71920] ShardingCatalogManager::updateTimeSeriesGranularity does not take _kChunkOpLock Created: 07/Dec/22  Updated: 29/Oct/23  Resolved: 23/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0-rc0

Type: Bug Priority: Major - P3
Reporter: Jordi Serra Torrens Assignee: Antonio Fuschetto
Resolution: Fixed Votes: 0
Labels: sharding-wfbf-day
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-61028 Implement granularity update for time... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding EMEA 2022-12-26, Sharding EMEA 2023-01-09, Sharding EMEA 2023-01-23
Participants:

 Description   

ShardingCatalogManager::updateTimeSeriesGranularity calls bumpMajorVersionOneChunkPerShard, which was originally meant to be called with the _kChunkOpLock held. This is needed because bumpMajorVersionOneChunkPerShard will need to compute a new updated collectionVersion, so this requires serializing with any other possible update the collection version. However, updateTimeSeriesGranularity is not taking _kChunkOpLock.

This ticket is to take _kChunksOpLock in updateTimeSeriesGranularity and also to add a comment on bumpMajorVersionOneChunkPerShard's declaration noting that it requires that lock to be held. Additionally, we could add an invariant that the lock is held.



 Comments   
Comment by Githook User [ 23/Jan/23 ]

Author:

{'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}

Message: SERVER-71920 Serialize collection version updates in `ShardingCatalogManager::updateTimeSeriesGranularity`
Branch: master
https://github.com/mongodb/mongo/commit/9120256a24e77a66eca0c110ddc1179f4f11c8fc

Generated at Thu Feb 08 06:20:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.