[SERVER-72054] getPostBatchResumeToken accesses the recordId slot after EOF Created: 12/Dec/22 Updated: 17/Jan/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Anna Wawrzyniak | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
getPostBatchResumeToken may be called after the underling stage returned EOF. Its current implementation uses recordSlotId to obtain recordId of last slot. However, one stage return EOF that slot is not longer valid and should not be accessed. https://github.com/10gen/mongo/blob/master/src/mongo/db/commands/getmore_cmd.cpp#L451
Suggested fix: Make local copy of recordId in the executor that can be used instead of accessing the slot that may be invalidated. |
| Comments |
| Comment by Anna Wawrzyniak [ 20/Dec/22 ] |
|
As long as recordIds are inlined within slots (so no BigString), then accessing the recordId slot past EOF will currently result in getting the value cached in the slot, which for simple scan queries should be the last recordId. However, SBE does not guarantee that this cached value will be present there after EOF. It currently happens to be there and but in the future it might no longer be the case. If this code path is only utilized by change streams, and change streams don't use SBE then fixing this is a low priority. However, I think we should fix before using this code path in production. |
| Comment by Brenda Rodriguez [ 20/Dec/22 ] |
|
anna.wawrzyniak@mongodb.com is this a problem in practice? We are not sure because change streams never uses SBE right now. |