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

Multiple birthmarks per key being stored in lookaside

    • Type: Icon: Bug Bug
    • Resolution: Duplicate
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Engines 2019-07-19

      While working on WT-4674, I came across this potential bug:

      Other than creating a birthmark record in lookaside for the on-disk value, we are also inserting in lookaside the birthmark updates from the update chain. After going through a series of lookaside eviction and re-instantiation, a page will potentially end up with several birthmark records per key. This is unexpected and needs to be investigated and understood if there is a bug here.

      Steps to reproduce:

      1. Add an assert that we are not inserting a birthmark into lookaside other than for the on-disk value
      2. Run test_las02.py to hit the assert.

      diff --git a/src/cache/cache_las.c b/src/cache/cache_las.c
      index 6b1a82d08..661931b5f 100644
      --- a/src/cache/cache_las.c
      +++ b/src/cache/cache_las.c
      @@ -791,10 +791,12 @@ __wt_las_insert_block(WT_CURSOR *cursor,
                                          upd->start_ts, upd->durable_ts,
                                          upd->prepare_state, WT_UPDATE_BIRTHMARK,
                                          &las_value);
      -                       } else
      +                       } else {
      +                               WT_ASSERT(session, upd->type != WT_UPDATE_BIRTHMARK);
                                      cursor->set_value(cursor, upd->txnid,
                                          upd->start_ts, upd->durable_ts,
                                          upd->prepare_state, upd->type, &las_value);
      +                       }
       
                              /*
                               * Using update looks a little strange because the keys
      
      test_las02.test_las02.test_las: started in WT_TEST/test_las02.test_las02.test_las.0
      test_las02.test_las02.test_las (subunit.RemotedTestCase)
      test_las02.test_las02.test_las ... ERROR
      
      ======================================================================
      ERROR: test_las02.test_las02.test_las (subunit.RemotedTestCase)
      test_las02.test_las02.test_las
      ----------------------------------------------------------------------
      _StringException: lost connection during test 'test_las02.test_las02.test_las'
      
      ----------------------------------------------------------------------
      Ran 1 test in 1.847s
      
      FAILED (errors=1)
      
      $ cat WT_TEST/test_las02.test_las02.test_las.0/stderr.txt
      [1562648573:541810][8515:0x7f91577fe700], test_las02.test_las02.test_las, file:las02_main.wt, eviction-server: __wt_las_insert_block, 795: upd->type != WT_UPDATE_BIRTHMARK
      [1562648573:541876][8515:0x7f91577fe700], test_las02.test_las02.test_las, file:las02_main.wt, eviction-server: __wt_abort, 30: aborting WiredTiger library
      

            Assignee:
            alex.cameron@mongodb.com Alex Cameron (Inactive)
            Reporter:
            sulabh.mahajan@mongodb.com Sulabh Mahajan
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: