[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: |
| 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. |