[SERVER-33951] Abort transactions when the pending writes pass 16MB worth of write data Created: 16/Mar/18  Updated: 29/Oct/23  Resolved: 13/Apr/18

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Matthew Russotto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-04-23
Participants:

 Description   

In addition to failing at commit time if the applyOps oplog entry that would get written is over 16Mb, we should also pro-actively abort transactions before they reach commit time if the in-memory OperationDescriptions of the pending writes passes 16Mb



 Comments   
Comment by Githook User [ 13/Apr/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-33951 Abort transactions when the pending writes pass 16MB worth of write data
Branch: master
https://github.com/mongodb/mongo/commit/7c65bad3c3dd5e9fe47cdb835d5374113596df3e

Comment by Daniel Gottlieb (Inactive) [ 16/Mar/18 ]

Is this just an optimization, or is this required to be "perfect"? I.e: if the transaction is not proactively aborted, must it be guaranteed for the applyOps oplog entry to be less than 16MB?

An `applyOps` document has additional overhead because of the other fields it contains in addition to the the "keys" being numeric strings. Calculating the size a series of oplog entries would combine into is hard without actually performing the serialization.

Edit After rereading, I can now see this check should be in addition to failing at commit time due to the oplog size. I didn't realize the motivation for this ticket was preventing resource exhaustion.

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