1. 09 Nov, 2015 3 commits
    • antirez's avatar
      Use clientHasPendingReplies() in flushSlavesOutputBuffers() · b719eedf
      antirez authored
      The old version only flushed data to slaves if there were strings
      pending in the client->reply list. Now also static buffers are flushed.
      Does not help to free memory (which is the only use we have right now in
      the fuction), but is more correct conceptually, and may be used in
      other contexts.
      b719eedf
    • antirez's avatar
      Scripting: fix redis.call() error reporting. · 1b5d24eb
      antirez authored
      Arguments arity and arguments type error of redis.call() were not
      reported correctly to Lua, so the command acted in this regard like
      redis.pcall(), but just for two commands. Redis.call() should always
      raise errors instead.
      1b5d24eb
    • antirez's avatar
      Fix error reply in subscribed Pub/Sub mode. · 111d24f2
      antirez authored
      PING is now a valid command to issue in this context.
      111d24f2
  2. 05 Nov, 2015 2 commits
  3. 04 Nov, 2015 1 commit
    • antirez's avatar
      Fix HINCRBYFLOAT to work with long doubles. · 71aa9b75
      antirez authored
      During the refactoring needed for lazy free, specifically the conversion
      of t_hash from struct robj to plain SDS strings, HINCRBFLOAT was
      accidentally moved away from long doubles to doubles for internal
      processing of increments and formatting.
      
      The diminished precision created more obvious artifacts in the way small
      numbers are formatted once we convert from decimal number in radix 10 to
      double and back to its string in radix 10.
      
      By using more precision, we now have less surprising results at least
      with small numbers like "1.23", exactly like in the previous versions of
      Redis.
      
      See issue #2846.
      71aa9b75
  4. 30 Oct, 2015 10 commits
  5. 21 Oct, 2015 1 commit
    • antirez's avatar
      CLIENT REPLY command implemented: ON, OFF and SKIP modes. · 86f0a2ee
      antirez authored
      Sometimes it can be useful for clients to completely disable replies
      from the Redis server. For example when the client sends fire and forget
      commands or performs a mass loading of data, or in caching contexts
      where new data is streamed constantly. In such contexts to use server
      time and bandwidth in order to send back replies to clients, which are
      going to be ignored, is a shame.
      
      Multiple mechanisms are possible to implement such a feature. For
      example it could be a feature of MULTI/EXEC, or a command prefix
      such as "NOREPLY SADD myset foo", or a different mechanism that allows
      to switch on/off requests using the CLIENT command.
      
      The MULTI/EXEC approach has the problem that transactions are not
      strictly part of the no-reply semantics, and if we want to insert a lot
      of data in a bulk way, creating a huge MULTI/EXEC transaction in the
      server memory is bad.
      
      The prefix is the best in this specific use case since it does not allow
      desynchronizations, and is pretty clear semantically. However Redis
      internals and client libraries are not prepared to handle this
      currently.
      
      So the implementation uses the CLIENT command, providing a new REPLY
      subcommand with three options:
      
          CLIENT REPLY OFF disables the replies, and does not reply itself.
          CLIENT REPLY ON re-enables the replies, replying +OK.
          CLIENT REPLY SKIP only discards the reply of the next command, and
                            like OFF does not reply anything itself.
      
      The reason to add the SKIP command is that it allows to have an easy
      way to send conceptually "single" commands that don't need a reply
      as the sum of two pipelined commands:
      
          CLIENT REPLY SKIP
          SET key value
      
      Note that CLIENT REPLY ON replies with +OK so it should be used when
      sending multiple commands that don't need a reply. However since it
      replies with +OK the client can check that the connection is still
      active and all the previous commands were received.
      
      This is currently just into Redis "unstable" so the proposal can be
      modified or abandoned based on users inputs.
      86f0a2ee
  6. 15 Oct, 2015 1 commit
  7. 14 Oct, 2015 2 commits
  8. 13 Oct, 2015 2 commits
  9. 09 Oct, 2015 1 commit
  10. 07 Oct, 2015 1 commit
    • antirez's avatar
      Fix extractLongLatOrReply() sanity check conditionals. · f29e3848
      antirez authored
      the check for lat/long valid ranges were performed inside the for loop,
      two times instead of one, and the first time when the second element of
      the array, xy[1], was yet not populated. This resulted into issue #2799.
      
      Close issue #2799.
      f29e3848
  11. 06 Oct, 2015 1 commit
  12. 05 Oct, 2015 1 commit
  13. 02 Oct, 2015 1 commit
  14. 01 Oct, 2015 13 commits