1. 26 Jun, 2018 1 commit
  2. 18 Jun, 2018 6 commits
  3. 17 Jun, 2018 1 commit
  4. 14 Jun, 2018 2 commits
    • antirez's avatar
      Sentinel: add an option to deny online script reconfiguration. · 6a66b93b
      antirez authored
      The ability of "SENTINEL SET" to change the reconfiguration script at
      runtime is a problem even in the security model of Redis: any client
      inside the network may set any executable to be ran once a failover is
      triggered.
      
      This option adds protection for this problem: by default the two
      SENTINEL SET subcommands modifying scripts paths are denied. However the
      user is still able to rever that using the Sentinel configuration file
      in order to allow such a feature.
      6a66b93b
    • antirez's avatar
      Fix infinite loop in dbRandomKey(). · d6e8fe77
      antirez authored
      Thanks to @kevinmcgehee for signaling the issue and reasoning about the
      consequences and potential fixes.
      
      Issue #5015.
      d6e8fe77
  5. 13 Jun, 2018 4 commits
  6. 12 Jun, 2018 12 commits
  7. 11 Jun, 2018 2 commits
    • antirez's avatar
      Use a less aggressive query buffer resize policy. · cec404f0
      antirez authored
      A user with many connections (10 thousand) on a single Redis server
      reports in issue #4983 that sometimes Redis is idle becuase at the same
      time many clients need to resize their query buffer according to the old
      policy.
      
      It looks like this was created by the fact that we allow the query
      buffer to grow without problems to a size up to PROTO_MBULK_BIG_ARG
      normally, but when the client is idle we immediately are more strict,
      and a query buffer greater than 1024 bytes is already enough to trigger
      the resize. So for instance if most of the clients stop at the same time
      this issue should be easily triggered.
      
      This behavior actually looks odd, and there should be only a clear limit
      after we say, let's look at this query buffer to check if it's time to
      resize it. This commit puts the limit at PROTO_MBULK_BIG_ARG, and the
      check is performed both if compared to the peak usage the current usage
      is too big, or if the client is idle.
      
      Then when the check is performed, to waste just a few kbytes is
      considered enough to proceed with the resize. This should fix the issue.
      cec404f0
    • antirez's avatar
      Fix client unblocking for XREADGROUP, issue #4978. · 34bd4418
      antirez authored
      We unblocked the client too early, when the group name object was no
      longer valid in client->bpop, so propagating XCLAIM later in
      streamPropagateXCLAIM() deferenced a field already set to NULL.
      34bd4418
  8. 10 Jun, 2018 3 commits
  9. 09 Jun, 2018 1 commit
  10. 08 Jun, 2018 1 commit
  11. 07 Jun, 2018 5 commits
  12. 06 Jun, 2018 2 commits