[SERVER-61182] [inMemory] collmod_convert_to_unique.js fails under in-memory storage engine Created: 02/Nov/21 Updated: 10/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Benety Goh | Assignee: | Backlog - Storage Engines Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | refinement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Storage Engines
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | StorEng - Refinement Pipeline, Asparagus-StorEng - 2023-10-31 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Story Points: | 2 | ||||||||||||||||
| Description |
|
This test was introduced in |
| Comments |
| Comment by Alexander Gorrod [ 01/Dec/23 ] | |||||||||||||||||||
|
Thanks yuhong.zhang@mongodb.com. steve.kuhn@mongodb.com could you please create a project titled "Altering table metadata without exclusive access in WiredTiger" (or similar), so we can get more specific about how much work would be involved on the WiredTiger side to support it, and find a way to get it scheduled. | |||||||||||||||||||
| Comment by Yuhong Zhang [ 16/Nov/23 ] | |||||||||||||||||||
|
alexander.gorrod@mongodb.com alter is used by collMod which is a replicated command used to modify collection metadata. This can cause a problem when we have a replica set with a mix of nodes running in-memory and on-disk storage engine. Currently there is really not a good solution to this problem so we would like to check again if it's possible to fix alter for in-memory engine. | |||||||||||||||||||
| Comment by Alexander Gorrod [ 25/Oct/23 ] | |||||||||||||||||||
|
This is not simple to fix. The alter operation requires exclusive access to a data handle, which generally involves closing the handle and flushing associated content from the cache. It is not possible to do that when running with an in-memory only configuration, as the cache is the only place where the data exists. It should (on some level) be safe for the alter to proceed without needing exclusive access, since it does not need to be concerned about the durability of the change (there is no durability). It's quite a lot of work to add a different concurrency control mechanism to handle alter commands, and given that this has remained as-is for a fair while without user-complaint, I'm inclined to close it out. The engineering effort required isn't justified given the minimal end-user consequence. benety.goh@mongodb.com please re-open with additional context if this is the wrong decision. | |||||||||||||||||||
| Comment by Etienne Petrel [ 13/Dec/21 ] | |||||||||||||||||||
|
Error when running the repo:
I dug into the code and I found this ticket I removed those few lines from the code and the test runs successfully:
It was a very quick investigation, we probably need to assess the impact(s) of allowing the alter command to be executed when WT is configured to be in memory.
| |||||||||||||||||||
| Comment by Deepti Hasija [ 25/Nov/21 ] | |||||||||||||||||||
|
Scope: Investigate and create a WT ticket if there is a fix required at the WT end. |