1. 20 Jul, 2020 2 commits
    • WuYunlong's avatar
      Fix cluster redirect for module command with no firstkey. (#7539) · e4d7de60
      WuYunlong authored
      Before this commit, processCommand() did not notice that cmd could be a module command
      which declared `getkeys-api` and handled it for the purpose of cluster redirect it
      as if it doesn't use any keys.
      
      This commit fixed it by reusing the codes in addReplyCommand().
      e4d7de60
    • WuYunlong's avatar
      Refactor streamAppendItem() by deleting redundancy condition. (#7487) · 86fed3fe
      WuYunlong authored
      It will never happen that "lp != NULL && lp_bytes >= server.stream_node_max_bytes".
      Assume that "lp != NULL && lp_bytes >= server.stream_node_max_bytes",
      we got the following conditions:
      a. lp != NULL
      b. lp_bytes >= server.stream_node_max_bytes
      
      If server.stream_node_max_bytes is 0, given condition a, condition b is always satisfied
      If server.stream_node_max_bytes is not 0, given condition a and condition b, the codes just a
      	few lines above set lp to NULL, a controdiction with condition a
      
      So that condition b is recundant. We could delete it safely.
      86fed3fe
  2. 16 Jul, 2020 2 commits
  3. 15 Jul, 2020 6 commits
  4. 14 Jul, 2020 1 commit
    • Oran Agra's avatar
      diskless master disconnect replicas when rdb child failed (#7518) · a176cb56
      Oran Agra authored
      in case the rdb child failed, crashed or terminated unexpectedly redis
      would have marked the replica clients with repl_put_online_on_ack and
      then kill them only after a minute when no ack was received.
      
      it would not stream anything to these connections, so the only effect of
      this bug is a delay of 1 minute in the replicas attempt to re-connect.
      a176cb56
  5. 13 Jul, 2020 2 commits
  6. 11 Jul, 2020 2 commits
  7. 10 Jul, 2020 12 commits
  8. 25 Jun, 2020 1 commit
  9. 24 Jun, 2020 1 commit
  10. 23 Jun, 2020 1 commit
    • Oran Agra's avatar
      EXEC always fails with EXECABORT and multi-state is cleared · 65a3307b
      Oran Agra authored
      In order to support the use of multi-exec in pipeline, it is important that
      MULTI and EXEC are never rejected and it is easy for the client to know if the
      connection is still in multi state.
      
      It was easy to make sure MULTI and DISCARD never fail (done by previous
      commits) since these only change the client state and don't do any actual
      change in the server, but EXEC is a different story.
      
      Since in the past, it was possible for clients to handle some EXEC errors and
      retry the EXEC, we now can't affort to return any error on EXEC other than
      EXECABORT, which now carries with it the real reason for the abort too.
      
      Other fixes in this commit:
      - Some checks that where performed at the time of queuing need to be re-
        validated when EXEC runs, for instance if the transaction contains writes
        commands, it needs to be aborted. there was one check that was already done
        in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
        -NOREPLICAS, -MASTERDOWN
      - When a command is rejected by processCommand it was rejected with addReply,
        which was not recognized as an error in case the bad command came from the
        master. this will enable to count or MONITOR these errors in the future.
      - make it easier for tests to create additional (non deferred) clients.
      - add tests for the fixes of this commit.
      65a3307b
  11. 22 Jun, 2020 4 commits
  12. 18 Jun, 2020 1 commit
  13. 17 Jun, 2020 1 commit
  14. 16 Jun, 2020 3 commits
  15. 15 Jun, 2020 1 commit