Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5587

Limit how many checkpoints are dropped by a subsequent checkpoint

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2, 4.2.4, 4.3.4, 4.0.17, 4.5.1, 3.6.19
    • Component/s: None
    • Labels:
      None
    • Case:
    • Story Points:
      2
    • Sprint:
      Storage Engines 2020-02-24
    • Backport Requested:
      v4.2, v4.0, v3.6

      Description

      Summary:
      Only drop a maximum of 4 previous checkpoints, during a checkpoint, so the first checkpoint after a hot backup cursor is closed doesn't take a huge amount of time to complete.


      There is code in checkpoint that cleans up obsolete checkpoints as soon as they become obsolete. Significant parts of that cleanup happen while holding locks that interrupt other operations (like opening cursors in some cases). When a backup cursor is open for a long period of time a lot of checkpoints are accumulated, and those checkpoints all become eligible for cleanup as soon as the backup cursor is closed.

      We should limit the number of checkpoint handles cleaned up with each checkpoint. My recommendation would be cleaning up between 2 and 4 checkpoints per file per checkpoint.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              keith.bostic Keith Bostic
              Reporter:
              alexander.gorrod Alexander Gorrod
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: