1. 28 Oct, 2019 2 commits
    • swilly22's avatar
      Introduce ReplyWithVerbatimString, ReplyWithEmptyArray, ReplyWithNullArray and... · 56a7c455
      swilly22 authored
      Introduce ReplyWithVerbatimString, ReplyWithEmptyArray, ReplyWithNullArray and ReplyWithEmptyString to redis module API
      56a7c455
    • zhaozhao.zz's avatar
      Modules: make unloading module more safe · c74398e1
      zhaozhao.zz authored
      As we know if a module exports module-side data types,
      unload it is not allowed. This rule is the same with
      blocked clients in module, because we use background
      threads to implement module blocked clients, and it's
      not safe to unload a module if there are background
      threads running. So it's necessary to check if any
      blocked clients running in this module when unload it.
      
      Moreover, after that we can ensure that if no modules,
      then no module blocked clients even module unloaded.
      So, we can call moduleHandleBlockedClients only when
      we have installed modules.
      c74398e1
  2. 25 Oct, 2019 1 commit
  3. 24 Oct, 2019 1 commit
  4. 23 Oct, 2019 26 commits
  5. 17 Oct, 2019 3 commits
  6. 16 Oct, 2019 1 commit
  7. 15 Oct, 2019 3 commits
  8. 10 Oct, 2019 2 commits
    • antirez's avatar
      Cluster: fix memory leak of cached master. · 747be463
      antirez authored
      This is what happened:
      
      1. Instance starts, is a slave in the cluster configuration, but
      actually server.masterhost is not set, so technically the instance
      is acting like a master.
      
      2. loadDataFromDisk() calls replicationCacheMasterUsingMyself() even if
      the instance is a master, in the case it is logically a slave and the
      cluster is enabled. So now we have a cached master even if the instance
      is practically configured as a master (from the POV of
      server.masterhost value and so forth).
      
      3. clusterCron() sees that the instance requires to replicate from its
      master, because logically it is a slave, so it calls
      replicationSetMaster() that will in turn call
      replicationCacheMasterUsingMyself(): before this commit, this call would
      overwrite the old cached master, creating a memory leak.
      747be463
    • Guy Benoish's avatar
      Fix usage of server.stream_node_max_* · 2fae0192
      Guy Benoish authored
      2fae0192
  9. 09 Oct, 2019 1 commit