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

Truncating an implicitly created range in FLCS could result in WT_ROLLBACK

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Column Store, Truncate
    • Storage Engines
    • StorEng - Defined Pipeline

      If a user creates a key past the end of an FLCS table, a concurrent transaction that tries to truncate any part of the implicitly created key range would result in WT_ROLLBACK.

      Steps to reproduce:

      1. Create an FLCS table.
      2. Begin a transaction and insert a key past the end of the range, e.g., 58.
      3. Begin another transaction and truncate a part of the key range, e.g., 30 through 56. This results in a transaction conflict.

      Here are the steps represented as a `test/model` workload:

      create_table(1, table, r, 8t)
      begin_transaction(1)
      insert(1, 1, 58, 40)
      begin_transaction(2)
      truncate(1, 2, 30, 56)
      commit_transaction(1, 93, 0)
      commit_transaction(2, 88, 0)
      

      This interaction should not constitute a transaction conflict because the inserted key in transaction 1 and the truncated range in transaction 2 are disjoint. In fact, there is no conflict when we run the same workload on the row store or the VLCS. Ideally, these semantics should be the same across all table types.

      This ticket is somewhat reminiscent of WT-12971, which covers a similar issue with remove, but the proposed fix (which is approved but not yet merged) does not fix the issue for truncate.

            Assignee:
            backlog-server-storage-engines [DO NOT USE] Backlog - Storage Engines Team
            Reporter:
            peter.macko@mongodb.com Peter Macko
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: