Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-53481

FSM threads race in secondary_reads_with_catalog_changes.js

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 4.9.0
    • None
    • None
    • None
    • Fully Compatible
    • ALL
    • Execution Team 2021-01-25
    • 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.

      Attachments

        Activity

          People

            louis.williams@mongodb.com Louis Williams
            lingzhi.deng@mongodb.com Lingzhi Deng
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: