Redefine the rules of checkpoint order for fake checkpoint.

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Engines
    • None
    • None

      We are currently using addr is empty as the fake point condition while order still follow the rule of a general checkpoint. So in code the file checkpoint metadata sync we cannot rely on the order and timestamp to identify whether the local checkpoint should be deprecated.

      We should check all the pathways that generates a fake checkpoint in checkpoint tree. Potential solutions including but not limits to:

      • use order = 1 for fake, and 2+ for normal, this include change to new_checkpoint order.
        • pro: we can rely on order only to identify a fake checkpoint
        • con: it's a redundant information to addr is empty, size == 0.
      • Rethink can we avoid generate a fake checkpoint, which means at least put one page into the btree when it's created or other ways.
        • pro: we can safely make the code repo tidy, and remove all the special flags for a fake checkpoint because it's no long exist.
        • con: it maybe complex and need to take care each appearance.
      • Use lsn to instead of auto increase order. y.ershov@mongodb.com 
        • pro: it's clear and sequence guaranteed.
        • con: the order will not play a generation rule and the readability will be questioned.

            Assignee:
            [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            Albert Song
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: