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

Only clear the read timestamp when releasing the transaction

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • WT10.0.0, 4.4.2, 4.8.0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • 5
    • Storage - Ra 2020-08-24, Storage - Ra 2020-09-07, Storage - Ra 2020-09-21

      In a cache pressure scenario, during transaction begin __wt_txn_begin we stall for the cache to freed to let it continue, but during this process, the provided read timestamp to the transaction gets lost and it led to return incorrect results based on the transaction visibility.

      The problematic code flow where the provided read timestamp is lost.

      #0  __wt_txn_clear_read_timestamp (session=0x555555dbf730) at ../src/txn/txn_timestamp.c:1186
      #1  0x00007ffff5997fe9 in __wt_txn_release_snapshot (session=0x555555dbf730) at ../src/txn/txn.c:140
      #2  0x00007ffff57dc6fe in __wt_txn_read_last (session=0x555555dbf730) at ../src/include/txn.i:1335
      #3  0x00007ffff57ddeaa in __cursor_reset (cbt=0x555555e971f0) at ../src/include/cursor.i:212
      #4  0x00007ffff57dedf7 in __wt_btcur_reset (cbt=0x555555e971f0) at ../src/btree/bt_cursor.c:423
      #5  0x00007ffff588a650 in __curfile_reset (cursor=0x555555e971f0) at ../src/cursor/cur_file.c:172
      #6  0x00007ffff58b6848 in __wt_cursor_cache (cursor=0x555555e971f0, dhandle=0x555555d88430) at ../src/cursor/cur_std.c:652
      #7  0x00007ffff588ed69 in __curfile_cache (cursor=0x555555e971f0) at ../src/cursor/cur_file.c:544
      #8  0x00007ffff58b6f0b in __wt_cursor_cache_release (session=0x555555dbf730, cursor=0x555555e971f0, released=0x7fffffffc447) at ../src/cursor/cur_std.c:735
      #9  0x00007ffff588ea39 in __curfile_close (cursor=0x555555e971f0) at ../src/cursor/cur_file.c:492
      #10 0x00007ffff58d72f9 in __wt_hs_cursor_close (session=0x555555dbf730, session_flags=0) at ../src/history/hs.c:259
      #11 0x00007ffff58d0062 in __wt_evict (session=0x555555dbf730, ref=0x7fffdc006570, previous_state=3 '\003', flags=0) at ../src/evict/evict_page.c:138
      #12 0x00007ffff58ccb3c in __evict_page (session=0x555555dbf730, is_server=false) at ../src/evict/evict_lru.c:2257
      #13 0x00007ffff58cd143 in __wt_cache_eviction_worker (session=0x555555dbf730, busy=false, readonly=true, pct_full=106.72405210036237)
          at ../src/evict/evict_lru.c:2344
      #14 0x00007ffff59624b4 in __wt_cache_eviction_check (session=0x555555dbf730, busy=false, readonly=true, didworkp=0x0) at ../src/include/cache.i:505
      #15 0x00007ffff5962eaf in __wt_txn_begin (session=0x555555dbf730, cfg=0x7fffffffc750) at ../src/include/txn.i:1089
      #16 0x00007ffff597294e in __session_begin_transaction (wt_session=0x555555dbf730, config=0x7ffff4640954 "read_timestamp=28") at ../src/session/session_api.c:1605
      

      I found the problem with the increase of number rows in the existing test_rollback_to_stable10.py test from 1000 to 2000 rows.

            Assignee:
            chenhao.qu@mongodb.com Chenhao Qu
            Reporter:
            haribabu.kommi@mongodb.com Haribabu Kommi
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: