[SERVER-13419] Plan summary string in slow query log is wrong if fell back to a non-blocking solution Created: 31/Mar/14 Updated: 06/Dec/22 Resolved: 05/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Querying |
| Affects Version/s: | 2.6.0-rc2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | David Storch | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The plan summary string is produced before or soon after newRunQuery(...) begins to a run a plan. However, the plan being used may change halfway through query execution. Specifically, if a blocking plan hits its memory limit, then we fall back on a non-blocking solution (the backup solution), but the slow query line will still contain the plan summary for the blocking plan. The following script will repro:
|
| Comments |
| Comment by Craig Homa [ 05/Aug/19 ] |
|
Closing because the backup plan path is very difficult to exercise in recent versions, so this bug is extremely rare. As opposed to fixing it, we should just remove the backup plan code since it is of questionable utility. david.storch will file a ticket to track that work. |
| Comment by David Storch [ 27/Jun/16 ] |
|
My reading of the code is that this issue can still theoretically occur on the 3.0, 3.2, and master branches. However, it is definitely the case that the particular repro script in this ticket no longer reproduces the issue. It does not reproduce on recent branches due to CachedPlanStage re-planning, which was introduced under That said, I think it may be difficult (perhaps impossible?) to exercise the MultiPlanStage fallback. Therefore, I suspect this issue to occur either rarely or not at all on versions >= 3.0.7. Let's keep this ticket open pending investigation of whether the MultiPlanStage fallback logic can ever be triggered. If it cannot be triggered, then it should be deleted. For what it's worth, our code coverage analysis indicates that the MultiPlanStage fallback code path is not being exercised by our test suites, which makes me suspect that it can be safely removed. |