[SERVER-51301] Have no-op writes for recording pre/post image documents be a side transaction Created: 01/Oct/20  Updated: 06/Feb/24

Status: Investigating
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 8.0 Required

Type: Improvement Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: storex-shortlist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-78482 Complete TODO listed in SERVER-51301 Blocked
Gantt Dependency
Related
related to SERVER-78482 Complete TODO listed in SERVER-51301 Blocked
related to SERVER-70903 support multi-oplog format for batche... Closed
related to SERVER-48771 Enforce constraints on "multi-timesta... Closed
related to SERVER-59443 Remove storeFindAndModifyImagesInSide... Closed
Assigned Teams:
Storage Execution
Sprint: Execution Team 2020-12-14, Execution Team 2020-12-28, Execution Team 2021-01-11, Execution Team 2021-03-22, Execution Team 2021-10-04, Execution Team 2021-10-18, Execution Team 2021-11-01, Sharding 2022-05-02
Participants:
Case:

 Description   

There are some types of requests that in a single storage transaction write multiple oplog entries. Because each oplog entry sets a different WT timestamp, there's risk that any data writes correlate with the wrong oplog entry.

There's a category of these cases where one of the oplog writes is a no-op write for recording pre/post images that get linked to a following oplog entry. Because the no-op entries themselves do not represent any data writes, it would be safer to write these no-oplog entries in their own storage transaction.

E.g:

Usages that will go away with SERVER-59443 and we can omit "fixing":



 Comments   
Comment by Daniel Gottlieb (Inactive) [ 16/Nov/21 ]

With a lot of work surrounding retryable writes, this ticket has aged poorly. The remaining piece of code has been identified as problematic by the internal transactions project. I'm going to move this ticket into that project with the expectation this will be closed as either:

  • Won't do
  • Gone away
  • Duplicate (of some future ticket)

When the internal transactions project has codified a timestamp story in place, we'll revisit where we suppress the multi timestamp constraint and determine what's best to do about them. For now this ticket is just a symbol that the general consensus is that we do want to get rid of these cases.

Comment by Daniel Gottlieb (Inactive) [ 03/Sep/21 ]

I recently edited the description to scope down this ticket (but I messed up a ticket number describing which cases would go away). I left one bullet point that I think this ticket should address: https://github.com/mongodb/mongo/blob/fa5aff14111de4fe23ae0094c597673cc4a48d3b/src/mongo/db/op_observer_impl.cpp#L1032-L1051.

Comment by Louis Williams [ 03/Sep/21 ]

daniel.gottlieb can you confirm that we no longer need to do this?

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