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

Only clear the read timestamp when releasing the transaction

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2, 4.4.2, 4.8.0
    • Component/s: None
    • Labels:
      None
    • Story Points:
      5
    • Sprint:
      Storage - Ra 2020-08-24, Storage - Ra 2020-09-07, Storage - Ra 2020-09-21

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved: