[SERVER-46265] fix memory limit situation with InternalRenameIfOptionsAndIndexesMatch so it can be relied upon for $out Created: 19/Feb/20 Updated: 04/Mar/20 Resolved: 04/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ted Tuckman | Assignee: | Ted Tuckman |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | qopt-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Query 2020-03-09 | ||||||||
| Participants: | |||||||||
| Description |
|
listIndexes could return a document larger than 16MB. The current scheme for InternalRenameIfOptionsAndIndexesMatch takes a single document of indexes. If a user has more indexes than 16MB this will error. |
| Comments |
| Comment by Ted Tuckman [ 04/Mar/20 ] |
|
There were no objections during discussion yesterday, closing. |
| Comment by Ted Tuckman [ 03/Mar/20 ] |
|
Because of the 64 index per collection limit, for someone to hit this issue they would have to have 64 indexes that serialize to ~ 4000 bytes each. This seems very unlikely, so I don't think we need to do anything about this. Will leave open for now so people can comment if they disagree, but my pitch would be close won't fix. |
| Comment by Ted Tuckman [ 21/Feb/20 ] |
|
david.storch I/We haven't given it much thought yet. This was leftover from when it was implemented for internalOutToDifferentDB since it seems very unlikely that a user would be in this situation. Will update once we decide whether its worth investigating and have figured out a path forward.
|
| Comment by David Storch [ 21/Feb/20 ] |
|
ted.tuckman can you elaborate on how you intend to fix this? |