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

SizeStorer can cause deadlocks with cache eviction

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.2.0, 5.0.6
    • Component/s: None
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Backport Requested:
      v5.0
    • Sprint:
      Execution Team 2021-11-15, Execution Team 2021-11-29
    • Linked BF Score:
      19

      Description

      This is a follow-up to WT-8245.

      There's a mutex inside the SizeStorer that serializes access to a global WT session and cursor that we keep open forever. We let multiple threads share it, which is where the mutex comes in. In general, it's not a good idea to hold an exclusive lock and call into the storage engine.

      The larger problem is that the SizeStorer uses a WT_SESISON that is not the one owned by the calling operation, which may also have its own WT_SESSION.

      In practice, this has only shown up in importCollection. After the operation has performed a catalog write, it gets stuck inside of SizeStorer::load, holds this mutex, and blocks on cache eviction. WiredTiger will roll back transactions that have written data, but it will not roll back read-only transactions. WiredTiger cannot roll-back the SizeStorer::load() because the SizeStorer uses an entirely separate WT_SESSION than the one that importCollection uses. So even though importCollection has written data, it cannot be rolled back even if it is causing cache issues.

      Using more than one WT_SESSION per thread is a bug that we've seen before.

      We should just get rid of this global session + cursor and require that callers pass their own OperationContext. If that's not possible for some reason, we'll need to use "cache_max_wait_ms" to allow the operation to time itself out.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              gregory.wlodarek Gregory Wlodarek
              Reporter:
              louis.williams Louis Williams
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: