[SERVER-59075] Create temporary RecordStore in HashAgg stage Created: 03/Aug/21  Updated: 29/Oct/23  Resolved: 15/Oct/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.2.0

Type: Task Priority: Major - P3
Reporter: Ian Boros Assignee: Eric Cox (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-58436 Implement spilling HashAgg Closed
Related
is related to SERVER-59969 Allow writing to temporary table with... Closed
Backwards Compatibility: Fully Compatible
Sprint: QE 2021-10-18
Participants:

 Description   

Before spilling can be done in the HashAgg stage, we need to be able to create a temporary RecordStore from SBE.

There are some complications around allowing writes on the recovery unit before this can be done. In the classic engine (see here) this is done by abandoning the current snapshot and calling setPrepareConflictBehavior(). For SBE, this will not be an option.



 Comments   
Comment by Githook User [ 14/Oct/21 ]

Author:

{'name': 'Eric Cox', 'email': 'eric.cox@mongodb.com', 'username': 'ericox'}

Message: SERVER-59075 Create temporary RecordStore in HashAgg stage
Branch: master
https://github.com/mongodb/mongo/commit/d8781cb284af784447af76e1a7bcebc4079cc4c9

Comment by Louis Williams [ 04/Aug/21 ]

I wonder if it makes sense to have all read-only queries set kIgnoreConflictsAllowWrites earlier on. We (generally speaking) only need to enforce prepare conflicts for writes since ignoring prepare conflicts violates snapshot isolation and usually shows an earlier version of a document or none at all. For writes, since MongoDB guarantees snapshot isolation in transactions, this leads to bugs because a transaction can make a decision or calculation based on stale information. For reads, the result of skipping prepared updates is much more benign since our queries only guarantee read-committed isolation anyways.

Generated at Thu Feb 08 05:46:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.