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

Timestamps can be set on transactions that don't trigger a visibility refresh

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.0-rc2
    • Component/s: Storage
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Storage 2017-11-13
    • Linked BF Score:
      0

      Description

      Currently the code expects all timestamped transactions, which have the potential to update visibility, to call WiredTigerOplogManager::triggerJournalFlush. There are code paths that can set timestamps but not result in calling this method.

      Some paths forward to consider include:

      1. A call to WiredTigerRecoveryUnit::setTimestamp immediately installs the journal flushing "change". One drawback to this is that some recovery units have their timestamp set multiple times. Care should be taken to not create multiple unnecessary "changes".
      2. Remove OplogInsertChange and have WiredTigerOplogManager::triggerJournalFlush be called directly by all timestamped recovery units before returning from _txnClose.
      3. Relax the WiredTigerOplogManager::_oplogJournalThreadLoop conditions to run a refresh loop. E.g: always run an iteration every 5 seconds even if it hasn't been notified.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: