[SERVER-40790] Test downgrading 4.2 to 4.0 and then commit when transaction is too large to fit in a single applyOps Created: 23/Apr/19  Updated: 29/Oct/23  Resolved: 09/May/19

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

Type: Task Priority: Major - P3
Reporter: Jason Chan Assignee: Jason Chan
Resolution: Fixed Votes: 0
Labels: bigtxns_upgrade_downgrade, bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-39799 Test unprepared transactions on FCV 4.0 Closed
Related
related to SERVER-41062 Always return TransactionTooLarge rat... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-05-20
Participants:

 Description   

We should test that when we have an uncommitted partial transaction that is larger than 16MB, doing a downgrade and then a commitTransaction should throw a TransactionTooLarge error.



 Comments   
Comment by Githook User [ 09/May/19 ]

Author:

{'email': 'jason.chan@10gen.com', 'name': 'Jason Chan', 'username': 'jasonjhchan'}

Message: SERVER-40790 Test downgrading from FCV4.2 to FCV4.0 with a large running transaction will fail on commit.
Branch: master
https://github.com/mongodb/mongo/commit/f8f40d2bc140d4e8cfbc09d934ccb17682ea0d7f

Comment by Siyuan Zhou [ 08/May/19 ]

jason.chan, I moved the backport ticket to SERVER-41062 since this ticket is about upgrade/downgrade of 4.2. Making a new SERVER ticket seems clearer.

Comment by Jason Chan [ 08/May/19 ]

We should backport the moving of the try clause in onTransactionCommit up to also cover the opsArray.done() call since it is possible for that call to throw a BSONObjectTooLarge exception.

The call in question on the 4.0 branch is here: https://github.com/mongodb/mongo/blob/ed33d2f8e66cd907ef13ee162f6a1dac3ff25672/src/mongo/db/op_observer_impl.cpp#L918

Comment by Siyuan Zhou [ 02/May/19 ]

You can imagine a huge delay before the abort or the interruption is not checked while OpObserver is about to write into oplog. Adding a fail-point to block there may be the way to expose the race. Aborting unprepared transactions is still helpful to speed the FCV change, but may not be sufficient for correctness.

Besides, I don't get why we have to abort all unprepared transactions in the onCommit() callback, since there's no synchronization around the in-memory FCV or the on-disk doc between this write and the readers. Aborting them in the downgrade code path seems more straightforward to me.

Comment by Jason Chan [ 02/May/19 ]

siyuan.zhou
It seems like we abort all active unprepared transactions on downgrade from 4.2 to 4.0.

Since vessyratcheva@gmail.com already wrote a test for this behavior here, I think we can mark this ticket as duplicated.

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