[SERVER-53481] FSM threads race in secondary_reads_with_catalog_changes.js Created: 22/Dec/20  Updated: 29/Oct/23  Resolved: 13/Jan/21

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

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

Issue Links:
Depends
Related
related to SERVER-50610 secondary_reads.js should not make as... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2021-01-25
Participants:
Linked BF Score: 12

 Description   

In this test, after SERVER-50610, the logic is roughly:

  • thread 0 always does inserts (with implicit createCollection) and create index on field x
  • All other threads do one of dropIndex, dropCollection, or scan index x (retry if index x not there because we assume thread 0 will create an index eventually)

However, if thread 0 completes before others, all other threads could hang if the index is dropped again after.

I think maybe we could make the dropIndex thread to always recreate one after dropping the index so we don't rely on tid:0 being there to create the index. In other words, we probably should never have dependencies between threads in FSM because some of them might finish before others.



 Comments   
Comment by Githook User [ 13/Jan/21 ]

Author:

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

Message: SERVER-53481 Fix race in secondary_reads_with_catalog_changes.js
Branch: master
https://github.com/mongodb/mongo/commit/34e32be7b869deea3fc100d4e60b08986fdc4528

Generated at Thu Feb 08 05:31:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.