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

LookupQuerySettingsForFind should not be checking the node's sharding recovery state

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 7.3.0-rc0
    • None
    • None
    • Fully Compatible
    • ALL
    • QE 2023-12-11, QE 2023-12-25, QE 2024-01-08, QE 2024-01-22

    Description

      As part of SERVER-77079, the lookupQuerySettingsForFind was made to rely on the intialisation status of sharding in order to decide from where to pick up the query settings for a find.

       

      Instead of relying on ShardingState API, we should check if the request comes from the internal Client. There are already similar checks throughout the codebase, such as:

      bool isInternalClient(OperationContext* opCtx) {
          return opCtx->getClient()->session() && opCtx->getClient()->isInternalClient();
      } 

      We should do the same as part of this ticket.

       

      Apart from that we should prioritize the IDHACK check, before anything else. This would speed up some of the industry workloads which run IDHACK queries, by not doing any unnecessary work (such as ShardingState check). (see screenshot)

      We should also put the serializationContext, right before the lookup call

      auto serializationContext = parsedFind.findCommandRequest->getSerializationContext(); 

      Attachments

        Activity

          People

            catalin.sumanaru@mongodb.com Catalin Sumanaru
            kaloian.manassiev@mongodb.com Kaloian Manassiev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: