[SERVER-38467] renameCollection across databases should not require an uninterruptible database X lock while cleaning up temp collections Created: 07/Dec/18  Updated: 29/Oct/23  Resolved: 18/Dec/18

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

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Eric Milkie
Resolution: Fixed Votes: 0
Labels: prepare_interruptibility, uninterruptibleLockGuardRemoval
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-12-31
Participants:
Story Points: 5

 Description   

Rename collection across databases creates temporary collections and, in the case of an error, drops these temporary collections. Dropping temporary collections acquires a Database X lock in a destructor which must succeed. If this thread is the only accessor of the temporary collections, there is no need to take such a strong lock.



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

Author:

{'username': 'milkie', 'email': 'milkie@10gen.com', 'name': 'Eric Milkie'}

Message: SERVER-38467 do not block interruption when cleaning up temp collection from rename
Branch: master
https://github.com/mongodb/mongo/commit/687969575ce7876ffcbcccd8b4453463719060c6

Comment by Eric Milkie [ 11/Dec/18 ]

Perhaps the simplest solution is to simply make the temp table cleanup interruptible. We can clear the kill flag first before cleaning up, in order to reset the interrupt state. If the operation again gets interrupted (an unlikely scenario), we will simply leave the temp table alone, and it will get automatically cleaned up at the next server restart or stepup.

Comment by Eric Milkie [ 11/Dec/18 ]

Actually, a strong lock is still required to drop any Collection in the catalog, since there is always the chance that a listCollections command is scanning the Collections and extracting their string names.
I am going to brainstorm some other solutions to this problem.

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