1. 27 Oct, 2020 1 commit
    • Oran Agra's avatar
      RESTORE ABSTTL won't store expired keys into the db (#7472) · e9c9e4c2
      Oran Agra authored
      Similarly to EXPIREAT with TTL in the past, which implicitly deletes the
      key and return success, RESTORE should not store key that are already
      expired into the db.
      When used together with REPLACE it should emit a DEL to keyspace
      notification and replication stream.
      
      (cherry picked from commit 5977a948)
      (cherry picked from commit 95ba01b5)
      e9c9e4c2
  2. 23 Apr, 2020 1 commit
    • srzhao's avatar
      Check OOM at script start to get stable lua OOM state. · 0efb93d0
      srzhao authored
      Checking OOM by `getMaxMemoryState` inside script might get different result
      with `freeMemoryIfNeededAndSafe` at script start, because lua stack and
      arguments also consume memory.
      
      This leads to memory `borderline` when memory grows near server.maxmemory:
      
      - `freeMemoryIfNeededAndSafe` at script start detects no OOM, no memory freed
      - `getMaxMemoryState` inside script detects OOM, script aborted
      
      We solve this 'borderline' issue by saving OOM state at script start to get
      stable lua OOM state.
      
      related to issue #6565 and #5250.
      0efb93d0
  3. 19 Nov, 2019 2 commits
  4. 14 Nov, 2019 1 commit
  5. 06 Nov, 2019 3 commits
    • antirez's avatar
      Update PR #6537: use a fresh time outside call(). · d3f4dec4
      antirez authored
      One problem with the solution proposed so far in #6537 is that key
      lookups outside a command execution via call(), still used a cached
      time. The cached time needed to be refreshed in multiple places,
      especially because of modules callbacks from timers, cluster bus, and
      thread safe contexts, that may use RM_Open().
      
      In order to avoid this problem, this commit introduces the ability to
      detect if we are inside call(): this way we can use the reference fixed
      time only when we are in the context of a command execution or Lua
      script, but for the asynchronous lookups, we can still use mstime() to
      get a fresh time reference.
      d3f4dec4
    • antirez's avatar
      Update PR #6537 patch to for generality. · 33f42665
      antirez authored
      After the thread in #6537 and thanks to the suggestions received, this
      commit updates the original patch in order to:
      
      1. Solve the problem of updating the time in multiple places by updating
      it in call().
      2. Avoid introducing a new field but use our cached time.
      
      This required some minor refactoring to the function updating the time,
      and the introduction of a new cached time in microseconds in order to
      use less gettimeofday() calls.
      33f42665
    • zhaozhao.zz's avatar
      expires: refactoring judgment about whether a key is expired · 68d71d83
      zhaozhao.zz authored
      Calling lookupKey*() many times to search a key in one command
      may get different result.
      
      That's because lookupKey*() calls expireIfNeeded(), and delete
      the key when reach the expire time. So we can get an robj before
      the expire time, but a NULL after the expire time.
      
      The worst is that may lead to Redis crash, for example
      `RPOPLPUSH foo foo` the first time we get a list form `foo` and
      hold the pointer, but when we get `foo` again it's expired and
      deleted. Now we hold a freed memory, when execute rpoplpushHandlePush()
      redis crash.
      
      To fix it, we can refactor the judgment about whether a key is expired,
      using the same basetime `server.cmd_start_mstime` instead of calling
      mstime() everytime.
      68d71d83
  6. 25 Sep, 2019 1 commit
  7. 05 Sep, 2019 1 commit
  8. 13 May, 2019 2 commits
  9. 10 May, 2019 1 commit
  10. 10 Apr, 2019 1 commit
  11. 14 Mar, 2019 4 commits
  12. 12 Dec, 2018 1 commit
  13. 11 Dec, 2018 2 commits
  14. 17 Oct, 2018 2 commits
  15. 15 Oct, 2018 1 commit
  16. 09 Oct, 2018 1 commit
  17. 03 Oct, 2018 1 commit
  18. 14 Sep, 2018 2 commits
  19. 04 Sep, 2018 2 commits
  20. 29 Aug, 2018 3 commits
  21. 02 Aug, 2018 2 commits
  22. 30 Jul, 2018 3 commits
  23. 23 Jul, 2018 2 commits
    • Itamar Haber's avatar
    • Itamar Haber's avatar
      Adds memory information about the script's cache to INFO · faf3dbfc
      Itamar Haber authored
      Implementation notes: as INFO is "already broken", I didn't want to break it further. Instead of computing the server.lua_script dict size on every call, I'm keeping a running sum of the body's length and dict overheads.
      
      This implementation is naive as it **does not** take into consideration dict rehashing, but that inaccuracy pays off in speed ;)
      
      Demo time:
      
      ```bash
      $ redis-cli info memory | grep "script"
      used_memory_scripts:96
      used_memory_scripts_human:96B
      number_of_cached_scripts:0
      $ redis-cli eval "" 0 ; redis-cli info memory | grep "script"
      (nil)
      used_memory_scripts:120
      used_memory_scripts_human:120B
      number_of_cached_scripts:1
      $ redis-cli script flush ; redis-cli info memory | grep "script"
      OK
      used_memory_scripts:96
      used_memory_scripts_human:96B
      number_of_cached_scripts:0
      $ redis-cli eval "return('Hello, Script Cache :)')" 0 ; redis-cli info memory | grep "script"
      "Hello, Script Cache :)"
      used_memory_scripts:152
      used_memory_scripts_human:152B
      number_of_cached_scripts:1
      $ redis-cli eval "return redis.sha1hex(\"return('Hello, Script Cache :)')\")" 0 ; redis-cli info memory | grep "script"
      "1be72729d43da5114929c1260a749073732dc822"
      used_memory_scripts:232
      used_memory_scripts_human:232B
      number_of_cached_scripts:2
       19:03:54 redis [lua_scripts-in-info-memory L ✚…⚑] $ redis-cli evalsha 1be72729d43da5114929c1260a749073732dc822 0
      "Hello, Script Cache :)"
      ```
      faf3dbfc