[SERVER-78353] [CQF] Investigate reference tracker stack-overflow Created: 22/Jun/23 Updated: 29/Aug/23 Resolved: 29/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matt Boros | Assignee: | David Percy |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||
| Sprint: | QO 2023-07-24, QO 2023-08-07, QO 2023-08-21, QO 2023-09-04 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
The maximum number of aggregation stages allowed is 1000 for non-debug builds. For the following pipeline (and other long pipelines) the classic engine has no issues, while Bonsai fails with a stack overflow in the first call to the reference tracker.
We should investigate why the stack frames are so large. Are we allocating unnecessarily at all? The overall goal is to determine if the transport infrastructure needs to fundamentally change to be able to handle deep trees, or is there a less extreme change we can make? |
| Comments |
| Comment by David Percy [ 29/Aug/23 ] |
|
After some discussion we've decided to:
|
| Comment by Matt Boros [ 28/Jun/23 ] |
|
I've found that this is also an issue for M2 queries. Repeating {$project: {a: 1}} one thousand times also causes stack overflow in the reference tracker. |
| Comment by Matt Boros [ 22/Jun/23 ] |
|
Note that this failure occurs in the first call to the reference tracker, before any rewrites or real work is done by the optimizer. We may fix this issue with the reference tracker and still have overflow issues with Bonsai for this query. |