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

Nested LFR collection helpers must not try to re-establish read source

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.9.0
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Requested:
      v4.9
    • Sprint:
      Execution Team 2021-03-22, Execution Team 2021-04-05
    • Linked BF Score:
      122

      Description

      TLDR; we still run the read source selection code in nested lock-free collection helpers. That read source selection may attempt to open a snapshot via RecoveryUnit::setTimestampReadSource(), which invariants if a snapshot is already open.

      We must not try to re-establish the read source. We already have a matching in-mem and on-disk snapshot at that point and should just run with it, disregarding repl state changes.
      -------------------------------------------------------
      My analysis from the test failure ticket:

      SBE has multiple AutoGetColl*LockFree instances in play. I think we opened a snapshot in one AutoGet*LockFree in mode secondary, stepped up to PRIMARY, and then in a subsequent AutoGet*LockFree this code to select read source ran a second time returning a different result and provoked another setTimestampReadSource() request that invariant'ed on an already open snapshot.

      I think our problem is that nested AutoGet*LockFree still run the establish read source logic repeatedly along with the Collection fetch.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dianna.hohensee Dianna Hohensee
              Reporter:
              dianna.hohensee Dianna Hohensee
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: