[SERVER-53591] Update coll_mod_takes_database_x_lock.js to reflect the fact that collMod takes a collection MODE_X lock now, not a database exclusive lock Created: 05/Jan/21 Updated: 29/Oct/23 Resolved: 15/Mar/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Yujin Kang Park |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, newgrad | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Execution Team 2022-03-07, Execution Team 2022-03-21 |
| Participants: |
| Description |
|
collMod takes a MODE_X collection lock now, it does not take a database X lock. However, the jstest indicates it expects a database X lock, whereas it appears to only check for a minimum of an database intent lock, and therefore is not failing. |
| Comments |
| Comment by Githook User [ 15/Mar/22 ] | |||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}Message: | |||||||||||||||||||||||||||||||||||||||
| Comment by Dianna Hohensee (Inactive) [ 14/Mar/22 ] | |||||||||||||||||||||||||||||||||||||||
|
I highly suspect that the extra MODE_X collection lock is on the database's views collection. Looking at the code, we always take the views collection lock, too. Seems like we don't actually need to take it all the time like we do, e.g. the AutoGetCollection could check for a view immediately before taking the views lock, unless there's an undocumented dependency somewhere to have access to the views collection in collMod. I'm not sure why the collection doesn't have a name. A pretty plausible notion, though, could be that the collection doesn't exist and so cannot have a nss resolution for lockInfo. So we have a ResourceId entry in the LockManager, presumably for the views collection, but no namespace name. Note for Yujin: we only create a <db>.system.views collection if a view is created in that database. Update: Yup, it's the views collection. I added
and I got
| |||||||||||||||||||||||||||||||||||||||
| Comment by Louis Williams [ 11/Mar/22 ] | |||||||||||||||||||||||||||||||||||||||
|
yujin.kang I think you're running into | |||||||||||||||||||||||||||||||||||||||
| Comment by Louis Williams [ 11/Mar/22 ] | |||||||||||||||||||||||||||||||||||||||
|
yujin.kang, we can rename the test safely without issue. | |||||||||||||||||||||||||||||||||||||||
| Comment by Connie Chen [ 13/Dec/21 ] | |||||||||||||||||||||||||||||||||||||||
|
We should change the test to not run in multiversion suites. | |||||||||||||||||||||||||||||||||||||||
| Comment by Dianna Hohensee (Inactive) [ 07/Jan/21 ] | |||||||||||||||||||||||||||||||||||||||
|
Note: looks like we won't be able to change the failpoint name without causing a backwards compatibility problem in multiversion suites running JS tests using the failpoint. |