[SERVER-44127] Accessing multiple collections in an operation on a secondary can crash Created: 21/Oct/19  Updated: 29/Oct/23  Resolved: 26/Nov/19

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

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Eric Milkie
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Execution Team 2019-11-04, Execution Team 2019-11-18, Execution Team 2019-12-02
Participants:
Linked BF Score: 10

 Description   

This is one of those "pick two of the three properties" except it's pick "X of the Y properties" for unknown values of X and Y.
The properties:

  • Allow lazy accessing of collections (i.e: not known ahead of time) after acquiring a storage engine snapshot.
  • Have instances of ghost timestamping catalog operations.
  • Not maintaining a versioned catalog.
  • Reacquire snapshots with different locks on a catalog conflict.
  • Ensure user operations don't fail due to a catalog conflicts.

It might be easiest to uassert when an operation cannot easily get a snapshot that is allowed to read from all necessary collections.



 Comments   
Comment by Githook User [ 25/Nov/19 ]

Author:

{'name': 'Eric Milkie', 'username': 'milkie', 'email': 'milkie@mongodb.com'}

Message: SERVER-44127 abort ops that encounter a catalog conflict after already locking in a read snapshot
Branch: master
https://github.com/mongodb/mongo/commit/bd31dd168c29d5aaa5ae2822f5673eff7a2850d7

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