[SERVER-64624] Make OpObserver check the recordPreImages option when determining where to store the pre-image for retryable findAndModify executed in an internal transaction Created: 17/Mar/22  Updated: 29/Oct/23  Resolved: 19/Mar/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Cheahuychou Mao Assignee: Cheahuychou Mao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-64605 Allow internal sessions on standalone... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding NYC 2022-04-04
Participants:

 Description   

SERVER-60540 made the OpObserver ignore the 'recordPreImages' (preImageRecordingEnabledForCollection) option when determining where to store the pre-image for an update or delete executed inside a retryable internal transaction. The rationale is that the 'recordPreImages' option is supported only on standalone replica sets and we planned to support internal transactions only on sharded clusters.

Starting in SERVER-64605, we now also support internal transactions on standalone replica sets. So OpObserver must account for the 'recordPreImages' option when determining where to store the pre-image. As a safety check, it should assert the mongod is not running in a sharded cluster if the 'recordPreImages' option is enabled since chunk migration currently cannot handle oplog entries with both a pre-image and a post-image (see this comment in SERVER-61188 for more info).



 Comments   
Comment by Githook User [ 18/Mar/22 ]

Author:

{'name': 'Cheahuychou Mao', 'email': 'mao.cheahuychou@gmail.com', 'username': 'cheahuychou'}

Message: SERVER-64624 Make OpObserver check the recordPreImages option when determining where to store the pre-image for retryable findAndModify executed in an internal transaction
Branch: master
https://github.com/mongodb/mongo/commit/29ac8dd086ca3dc2669740a53a930ed111a5b82c

Generated at Thu Feb 08 06:00:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.