[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: |
|
||||||||||||||||
| 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: |
| Comment by Siyuan Zhou [ 08/May/19 ] |
|
jason.chan, I moved the backport ticket to |
| 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 Since vessyratcheva@gmail.com already wrote a test for this behavior here, I think we can mark this ticket as duplicated. |