github.com/zuoyebang/bitalostable@v1.0.1-0.20240229032404-e3b99a834294/testdata/compaction_allow_zero_seqnum (about)

     1  define
     2  L2
     3    c.SET.2:2
     4  ----
     5  2:
     6    000004:[c#2,SET-c#2,SET]
     7  
     8  allow-zero-seqnum
     9  L0:b-b
    10  L0:c-c
    11  L0:d-d
    12  ----
    13  true
    14  false
    15  true
    16  
    17  allow-zero-seqnum
    18  L0:c-c L0:d-d
    19  L0:c-c L1:d-d
    20  L0:b-b L0:b-c
    21  L0:b-b L1:b-c
    22  ----
    23  false
    24  false
    25  false
    26  false
    27  
    28  # We only look for overlaps at L<N+2> as it isn't valid for a
    29  # compaction rooted at L<N> to not include overlapping tables at
    30  # L<N+1>.
    31  
    32  allow-zero-seqnum
    33  L1:c-c
    34  ----
    35  true
    36  
    37  # Regression test for a bug where the allow-zero-seqnum check was not
    38  # actually working for flushes due to a failure to clone the
    39  # lower-bound key used for checking for overlap. This caused the
    40  # overlap check to use [b,b] in the test below, rather than [a,b].
    41  
    42  define
    43  mem
    44    a.SET.2:2
    45    b.SET.3:3
    46  L1
    47    a.SET.0:0
    48  ----
    49  1:
    50    000004:[a#0,SET-a#0,SET]
    51  
    52  allow-zero-seqnum
    53  flush
    54  ----
    55  false
    56  
    57  # We never allow zeroing of seqnums during flushing as doing so runs
    58  # afoul of the WAL replay logic which flushes after each WAL is
    59  # replayed, but doesn't construct a version edit in between each
    60  # flush. Both disallowing of seqnum zeroing during flushing, and the
    61  # WAL replay behavior match RocksDB's behavior.
    62  
    63  define
    64  mem
    65    a.SET.2:2
    66    b.SET.3:3
    67  ----
    68  
    69  allow-zero-seqnum
    70  flush
    71  ----
    72  false