[SERVER-84852] Document work to make agg function with transactions and snapshot reads Created: 12/Jan/18  Updated: 12/Jan/24  Resolved: 01/Mar/18

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

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

Issue Links:
Related
is related to SERVER-33541 Add snapshot read support for aggrega... Closed
Sprint: Query 2018-01-29, Query 2018-02-26, Query 2018-03-12
Participants:

 Description   

presumably this will just be a list of SERVER tickets.



 Comments   
Comment by David Storch [ 01/Mar/18 ]

Closing, as I've done the research. Planning to take on the actual implementation work under SERVER-33541.

Comment by David Storch [ 28/Feb/18 ]

I don't think there's much work here, but I have a few open questions:

  • Should we make an effort to ban snapshot reads for aggregations that are actually reading metadata sources (as opposed to reading actual user data with DocumentSourceCursor, or DocumentSourceSampleFromRandomCursor)?
  • I think we could end up taking a lot of locks, or taking the same lock recursively many times. In particular $lookup could pose a problem. Any issues we foresee here? I assume we should at least write a test case to make sure this doesn't completely blow up?
  • In particular, I notice that the locking code will keep a list of resources to unlock when two-phase locking is enabled. Since $lookup normally acquires and drops locks repeatedly, this list could grow quite long. Is this a problem?
  • Anything somehow related to transactions (but not snapshot reads) that I might be missing?
  • Can I go ahead and file a server ticket? I have a patch in progress.
  • Need to ban $out and change streams? And probably geo near? I better audit the agg language to see if there is anything else that will cause trouble. $mergeCursors maybe?
Generated at Thu Feb 08 06:56:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.