1. 18 Dec, 2019 1 commit
  2. 19 Nov, 2019 2 commits
  3. 14 Nov, 2019 1 commit
  4. 06 Nov, 2019 1 commit
    • antirez's avatar
      Update PR #6537: use a fresh time outside call(). · 8b2c0f90
      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.
      8b2c0f90
  5. 05 Nov, 2019 2 commits
    • antirez's avatar
      Update PR #6537 patch to for generality. · 824f5f0b
      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.
      824f5f0b
    • zhaozhao.zz's avatar
      expires: refactoring judgment about whether a key is expired · e542132b
      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.
      e542132b
  6. 04 Nov, 2019 1 commit
  7. 29 Oct, 2019 1 commit
  8. 23 Oct, 2019 1 commit
  9. 27 Sep, 2019 1 commit
  10. 30 Jul, 2019 1 commit
  11. 22 Jul, 2019 2 commits
    • antirez's avatar
      Move signalFlushedDb() into a better place. · 436d02dd
      antirez authored
      Now that the call also invalidates client side caching slots, it is
      important that after an internal flush operation we both send the
      notifications to the clients and, at the same time, are able to reclaim
      the memory of the tracking table. This may even fix a few edge cases
      related to MULTI/EXEC + WATCH during resync, not sure, but in general
      looks more correct.
      436d02dd
    • antirez's avatar
      Client side caching: call the invalidation functions always. · 842b44dc
      antirez authored
      Otherwise what happens is that the tracking table will never get garbage
      collected if there are no longer clients with tracking enabled.
      Now the invalidation function immediately checks if there is any table
      allocated, otherwise it returns ASAP, so the overhead when the feature
      is not used should be near zero.
      842b44dc
  12. 17 Jul, 2019 2 commits
    • Oran Agra's avatar
      Module API for Forking · 56258c6b
      Oran Agra authored
      * create module API for forking child processes.
      * refactor duplicate code around creating and tracking forks by AOF and RDB.
      * child processes listen to SIGUSR1 and dies exitFromChild in order to
        eliminate a valgrind warning of unhandled signal.
      * note that BGSAVE error reply has changed.
      
      valgrind error is:
        Process terminating with default action of signal 10 (SIGUSR1)
      56258c6b
    • zhaozhao.zz's avatar
  13. 08 Jul, 2019 2 commits
    • Oran Agra's avatar
      diskless replication on slave side (don't store rdb to file), plus some other related fixes · 2de544cf
      Oran Agra authored
      The implementation of the diskless replication was currently diskless only on the master side.
      The slave side was still storing the received rdb file to the disk before loading it back in and parsing it.
      
      This commit adds two modes to load rdb directly from socket:
      1) when-empty
      2) using "swapdb"
      the third mode of using diskless slave by flushdb is risky and currently not included.
      
      other changes:
      --------------
      distinguish between aof configuration and state so that we can re-enable aof only when sync eventually
      succeeds (and not when exiting from readSyncBulkPayload after a failed attempt)
      also a CONFIG GET and INFO during rdb loading would have lied
      
      When loading rdb from the network, don't kill the server on short read (that can be a network error)
      
      Fix rdb check when performed on preamble AOF
      
      tests:
      run replication tests for diskless slave too
      make replication test a bit more aggressive
      Add test for diskless load swapdb
      2de544cf
    • Angus Pearson's avatar
  14. 03 Jul, 2019 1 commit
  15. 10 Jun, 2019 1 commit
  16. 02 Jun, 2019 1 commit
    • Oran Agra's avatar
      make redis purge jemalloc after flush, and enable background purging thread · 09f99c2a
      Oran Agra authored
      jemalloc 5 doesn't immediately release memory back to the OS, instead there's a decaying
      mechanism, which doesn't work when there's no traffic (no allocations).
      this is most evident if there's no traffic after flushdb, the RSS will remain high.
      
      1) enable jemalloc background purging
      2) explicitly purge in flushdb
      09f99c2a
  17. 22 May, 2019 1 commit
    • Angus Pearson's avatar
      Implement `SCAN cursor [TYPE type]` modifier suggested in issue #6107. · bf963253
      Angus Pearson authored
      Add tests to check basic functionality of this optional keyword, and also tested with
      a module (redisgraph). Checked quickly with valgrind, no issues.
      
      Copies name the type name canonicalisation code from `typeCommand`, perhaps this would
      be better factored out to prevent the two diverging and both needing to be edited to
      add new `OBJ_*` types, but this is a little fiddly with C strings.
      
      The [redis-doc](https://github.com/antirez/redis-doc/blob/master/commands.json) repo
      will need to be updated with this new arg if accepted.
      
      A quirk to be aware of here is that the GEO commands are backed by zsets not their own
      type, so they're not distinguishable from other zsets.
      
      Additionally, for sparse types this has the same behaviour as `MATCH` in that it may
      return many empty results before giving something, even for large `COUNT`s.
      bf963253
  18. 21 Mar, 2019 2 commits
  19. 19 Mar, 2019 1 commit
  20. 19 Feb, 2019 1 commit
  21. 21 Jan, 2019 3 commits
  22. 09 Jan, 2019 2 commits
  23. 31 Dec, 2018 1 commit
  24. 06 Dec, 2018 1 commit
  25. 24 Oct, 2018 1 commit
  26. 20 Oct, 2018 1 commit
  27. 19 Oct, 2018 2 commits
  28. 31 Jul, 2018 1 commit
  29. 25 Jul, 2018 2 commits