[SERVER-68199] An active index build on the existing target collection of a renameCollection command can fail the mongod Created: 21/Jul/22  Updated: 29/Oct/23  Resolved: 25/Jul/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.2.21
Fix Version/s: 4.2.22

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2022-07-25, Execution Team 2022-08-08
Participants:

 Comments   
Comment by Githook User [ 25/Jul/22 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-68199 Rename collection must check for index builds on the target collection before specially dropping indexes with names that are too long
Branch: v4.2
https://github.com/mongodb/mongo/commit/c808bc35dfe537a68961ec0fdfa5864793d550d7

Comment by Gregory Wlodarek [ 25/Jul/22 ]

Your suggestion to add an in-progress index build check before calling dropIndexesThatWillBeTooLongAfterDropPendingRename makes the most sense to me dianna.hohensee@mongodb.com.

Comment by Dianna Hohensee (Inactive) [ 21/Jul/22 ]

I looked into removing the dropIndexesThatWillBeTooLongAfterDropPendingRename call. We still rename collections out of the way for dropCollection for storage engines that do not support execution layer two-phase drop. Replication uses the DropPendingCollectionReaper after renaming the dropped collection out of the way, if execution two-phase drop isn't supported. Otherwise, execution two-phase drop obviates the need. In v4.2, regardless of FCV 4.0 or 4.2, however, the server seems just fine if I remove the dropIndexesThatWillBeTooLongAfterDropPendingRename call.

In v4.2, we do not need dropIndexesThatWillBeTooLongAfterDropPendingRename. We might still want to use it in FCV 4.0 in case binary downgrade to v3.6 occurs before the drop-pending namespace gets dropped? I haven't looked into the downgrade story from v4.2 to v3.6 for long index/collection names. If we do keep the function, then we just need to add a in-progress index build check to the path.

gregory.wlodarek@mongodb.com do you have any recommendations / knowledge add? IIRC, you worked on supporting longer names?

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