[SERVER-40177] Enforce prepare conflicts on secondaries Created: 15/Mar/19  Updated: 29/Oct/23  Resolved: 31/May/19

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

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: prepare_optional
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-40176 Cursor seekExact should not use WT_CU... Closed
is depended on by WT-4580 Abort transactions that perform updat... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2019-06-03
Participants:

 Description   

Once SERVER-39074 is complete, all operations default to enforcing prepare conflicts. Unfortunately, due to the problem described in SERVER-40176, this means that occasionally, prepare conflicts can be encountered when otherwise valid cursor seeks are adjacent to prepared records.

This is only problematic for "applyOps" entries because inserts ops are converted to upserts. This means a query on a nonexistent record, which uses search_near, can land on an adjacent record that is part of a prepared transaction, introducing a prepare conflict that would not have happened on a primary.

Transaction use "applyOps", but all inserts as part of transactions should be able to be applied as inserts instead of upserts. This also means prepare conflicts can be enforced during secondary batch application.



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

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-40177 Enforce prepare conflicts on secondaries
Branch: master
https://github.com/mongodb/mongo/commit/0c99d93518b8647a16897a3bf1bb318221a2ccec

Comment by Judah Schvimer [ 16/Mar/19 ]

IIUC, this is optional for "prepare" completion, but recommended for long term code safety. We are effectively relaxing a constraint during secondary oplog application that we should not have to relax.

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