|
For a retryable findAndModify statement that executes during a chunk migration, retryability is handled as follows.
For a retryable findAndModify statement that executes prior to a chunk migration, retryablity is handled quite differently in that _fetchNextOplogFromSessionCatalog() is responsible for both fetching and forging the pre/post image oplog entry for the write.
While this setup in _fetchNextNewWriteOplog() works for a regular retryable findAndModify, it will not work for a retryable findAndModify executed inside an internal transaction. Upon prepare or unprepared commit, the MigrationChunkClonerSourceLegacy could add the pre/post image opTime that it sees to session migration before adding the prepare or commit opTime to queue, however there is not a way for way to specify which statement the pre/post image opTime corresponds to. Since the SessionCatalogMigrationSource needs to traverse the transaction oplog chain anyway (in SERVER-63494), it is simpler for it to fetch the pre/post image oplog entry in _fetchNextNewWriteOplog() just like it does in _fetchNextOplogFromSessionCatalog(). Therefore, to avoid having separate logic for handling retryable findAndModify that executes inside and outside a transaction, we should do the following:
- Make the MigrationChunkClonerSourceLegacy not add pre/post image opTime to the session migration queue
- Make _fetchNextNewWriteOplog() use fetchPrePostImageOplog() to fetch or forge pre/post image oplog entry for each new write oplog entry here (i.e. remove this duplicated block of code), just like what _fetchNextOplogFromSessionCatalog() does.
|