[SERVER-26452] `renameCollection` should handle write conflicts Created: 04/Oct/16  Updated: 27/Feb/23  Resolved: 29/Mar/17

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.3.12
Fix Version/s: 3.2.14, 3.4.7, 3.5.6

Type: Bug Priority: Major - P3
Reporter: Samuel Rossi (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Done Votes: 0
Labels: bkp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-71674 Yield handlers not handling WCE throw... Blocked
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.4, v3.2
Steps To Reproduce:

Unfortunately I don't have a small test case that reproduces the error, but a write conflict can be reproduced by running the `agg_match.js` FSM concurrency test with an increased write conflict activation probability:

1. Change `jstests/concurrency/fsm_all.js` to call `runWorkLoadsSerially` on an array only containing "jstests/concurrency/fsm_workloads/agg_match.js" (instead of `ls(dir)`

2. In the function `setupWorkload` in `jstests/concurrency/fsm_libs/runner.js`, add the line `assert.commandWorked(myDB.adminCommand({configureFailPoint: "WTWriteConflictException", mode: {activationProbability: 0.0005}}));` (right after the declaration of the variable `myDB`)
3. Run resmoke with `--repeat=10 --executor=conncurrency jstests/concurrency/fsm_all.js`. A write conflict will occur within the first five or so iterations.

Sprint: Storage 2017-03-27, Storage 2017-04-17
Participants:
Linked BF Score: 0

 Description   

renameCollection (in "src/mongo/db/catalog/rename_collection.cpp") does not currently handle write conflicts. To do this, a retry loop needs to be added to ensure that that command succeeds.



 Comments   
Comment by Githook User [ 28/Jun/17 ]

Author:

{u'username': u'dgottlieb', u'name': u'Daniel Gottlieb', u'email': u'daniel.gottlieb@10gen.com'}

Message: SERVER-26452: WCE retry on renameCollection. Address possible dassert in dropIndex.

Add a write conflict retry loop around the fast-path for renameCollection,
when the source and target collection are in the same database.

Additionally, when indexes are being dropped, remove them from the
collection info cache before removing them from the catalog
(`_deleteFromDisk`). Removing an index from a catalog can result in
a WriteConflictException that triggers the rollback on the
IndexRemoveChange. The rollback adds the index back into the
collection info cache, which dasserts the index does not exist.

Lastly, this patch separates out the WTWriteConflictException failpoint
into one for modifications (WT_CUSOR::insert/remove etc...) and one
for reads (WT_CURSOR::search/next etc...). The new failpoint is named
`WTWriteConflictExceptionForReads`. Commands that only roll a die for
the read failpoint include `listCollections` and `validate`. This
distinction is useful for resmoke/js tests that are not resilent to
those commands failing with a write conflict.

(cherry picked from commit bc1a7d9aa34f3c7e61f89afa481e677e4981437d)
Branch: v3.4
https://github.com/mongodb/mongo/commit/fff65159be47d38e0333c0e75c778c62484a776b

Comment by Githook User [ 25/May/17 ]

Author:

{u'username': u'dgottlieb', u'name': u'Daniel Gottlieb', u'email': u'daniel.gottlieb@10gen.com'}

Message: SERVER-26452: WCE retry on renameCollection. Address possible dassert in dropIndex.

Add a write conflict retry loop around the fast-path for renameCollection,
when the source and target collection are in the same database.

Additionally, when indexes are being dropped, remove them from the
collection info cache before removing them from the catalog
(`_deleteFromDisk`). Removing an index from a catalog can result in
a WriteConflictException that triggers the rollback on the
IndexRemoveChange. The rollback adds the index back into the
collection info cache, which dasserts the index does not exist.

Lastly, this patch separates out the WTWriteConflictException failpoint
into one for modifications (WT_CUSOR::insert/remove etc...) and one
for reads (WT_CURSOR::search/next etc...). The new failpoint is named
`WTWriteConflictExceptionForReads`. Commands that only roll a die for
the read failpoint include `listCollections` and `validate`. This
distinction is useful for resmoke/js tests that are not resilent to
those commands failing with a write conflict.

(cherry picked from commit bc1a7d9aa34f3c7e61f89afa481e677e4981437d)
Branch: v3.2
https://github.com/mongodb/mongo/commit/a6e45b6f5c568dc280afe373536baa4e60a0b8de

Comment by Githook User [ 29/Mar/17 ]

Author:

{u'username': u'dgottlieb', u'name': u'Daniel Gottlieb', u'email': u'daniel.gottlieb@10gen.com'}

Message: SERVER-26452: WCE retry on renameCollection. Address possible dassert in dropIndex.

Add a write conflict retry loop around the fast-path for renameCollection,
when the source and target collection are in the same database.

Additionally, when indexes are being dropped, remove them from the
collection info cache before removing them from the catalog
(`_deleteFromDisk`). Removing an index from a catalog can result in
a WriteConflictException that triggers the rollback on the
IndexRemoveChange. The rollback adds the index back into the
collection info cache, which dasserts the index does not exist.

Lastly, this patch separates out the WTWriteConflictException failpoint
into one for modifications (WT_CUSOR::insert/remove etc...) and one
for reads (WT_CURSOR::search/next etc...). The new failpoint is named
`WTWriteConflictExceptionForReads`. Commands that only roll a die for
the read failpoint include `listCollections` and `validate`. This
distinction is useful for resmoke/js tests that are not resilent to
those commands failing with a write conflict.
Branch: master
https://github.com/mongodb/mongo/commit/bc1a7d9aa34f3c7e61f89afa481e677e4981437d

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