[SERVER-42123] dassert in IndexCatalogImpl::numIndexesTotal() can throw a WriteConflictException in debug builds Created: 09/Jul/19 Updated: 29/Oct/23 Resolved: 24/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Execution Team 2019-07-29 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 17 | ||||||||||||
| Description |
|
The dassert tries to read a record out of the catalog using KVCollectionCatalogEntry::getMetadata() which uses WiredTigerRecordStore::findRecord() and that could return a WriteConflictException when the WTSkipPrepareConflictRetries and skipWriteConflictRetries failpoints are enabled, preventing the WiredTigerRecordStore::findRecord() from retrying. Eventually this bubbles up to the caller as a WriteConflict. The dassert is a sanity check in debug builds to ensure that the in-memory index catalog matches the one on-disk. Running a command that doesn't expect a WriteConflictException such as the collStats command can return a WriteConflict error back to the user in this case. |
| Comments |
| Comment by Githook User [ 27/Dec/19 ] |
|
Author: {'name': 'Eric Milkie', 'email': 'milkie@mongodb.com', 'username': 'milkie'}Message: This reverts commit 458defe182cdd3fc6abedc53c6109b54d9192539. |
| Comment by Githook User [ 24/Jul/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Gregory Wlodarek [ 09/Jul/19 ] |
|
max.hirschhorn correct. Unfortunately getting the collection options to determine whether the collection is capped or not will do a read from disk today. Perhaps we can check whether the collection is capped or not prior to enabling the failpoints in the fuzzer code? |
| Comment by Max Hirschhorn [ 09/Jul/19 ] |
|
Do I understand correctly that the dassert() is causing the collStats command to trigger a prepare conflict for which the combination of the WTSkipPrepareConflictRetries and skipWriteConflictRetries failpoints is causing to manifest as a WriteConflict that gets returned back to the user? The goal of the rollback fuzzer running the collStats command is to determine whether the collection is capped or not. This is because we don't want to run the prepareTransaction command on a transaction started on a capped collection. If there's another way to glean the same information, then changing the rollback fuzzer and leaving the server's behavior alone is another option. |