1. 30 Oct, 2015 5 commits
    • antirez's avatar
      Lua script selective replication WIP. · a1d1ca14
      antirez authored
      a1d1ca14
    • antirez's avatar
      Scripting: single commands replication mode implemented. · cbbfaf6a
      antirez authored
      By calling redis.replicate_commands(), the scripting engine of Redis
      switches to commands replication instead of replicating whole scripts.
      This is useful when the script execution is costly but only results in a
      few writes performed to the dataset.
      
      Morover, in this mode, it is possible to call functions with side
      effects freely, since the script execution does not need to be
      deterministic: anyway we'll capture the outcome from the point of view
      of changes to the dataset.
      
      In this mode math.random() returns different sequences at every call.
      
      If redis.replicate_commnads() is not called before any other write, the
      command returns false and sticks to whole scripts replication instead.
      cbbfaf6a
    • antirez's avatar
    • antirez's avatar
      0259da8c
    • antirez's avatar
      CLIENT REPLY command implemented: ON, OFF and SKIP modes. · de4d6caf
      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.
      de4d6caf
  2. 27 Oct, 2015 1 commit
  3. 15 Oct, 2015 9 commits
  4. 09 Oct, 2015 4 commits
  5. 06 Oct, 2015 2 commits
  6. 01 Oct, 2015 9 commits
  7. 30 Sep, 2015 1 commit
    • antirez's avatar
      redis-cli pipe mode: don't stay in the write loop forever. · 0f81f83e
      antirez authored
      The code was broken and resulted in redis-cli --pipe to, most of the
      times, writing everything received in the standard input to the Redis
      connection socket without ever reading back the replies, until all the
      content to write was written.
      
      This means that Redis had to accumulate all the output in the output
      buffers of the client, consuming a lot of memory.
      
      Fixed thanks to the original report of anomalies in the behavior
      provided by Twitter user @fsaintjacques.
      0f81f83e
  8. 29 Sep, 2015 1 commit
  9. 15 Sep, 2015 1 commit
    • antirez's avatar
      Test: fix false positive in HSTRLEN test. · 846da5b2
      antirez authored
      HINCRBY* tests later used the value "tmp" that was sometimes generated
      by the random key generation function. The result was ovewriting what
      Tcl expected to be inside Redis with another value, causing the next
      HSTRLEN test to fail.
      846da5b2
  10. 14 Sep, 2015 4 commits
    • antirez's avatar
      GEORADIUS: Don't report duplicates when radius is huge. · 3c23b5ff
      antirez authored
      Georadius works by computing the center + neighbors squares covering all
      the area of the specified position and radius. Then a distance filter is
      used to remove elements which are actually outside the range.
      
      When a huge radius is used, like 5000 km or more, adjacent neighbors may
      collide and be the same, leading to the reporting of the same element
      multiple times. This only happens in the edge case of huge radius but is
      not ideal.
      
      A robust but slow solution would involve qsorting the range to remove
      all the duplicates. However since the collisions are only in adjacent
      boxes, for the way they are ordered in the code, it is much faster to
      just check if the current box is the same as the previous one processed.
      
      This commit adds a regression test for the bug.
      
      Fixes #2767.
      3c23b5ff
    • antirez's avatar
      Test: MOVE expire test improved. · 0a91fc45
      antirez authored
      Related to #2765.
      0a91fc45
    • antirez's avatar
      MOVE re-add TTL check fixed. · 4fec5ee1
      antirez authored
      getExpire() returns -1 when no expire exists.
      
      Related to #2765.
      4fec5ee1
    • antirez's avatar
      MOVE now can move TTL metadata as well. · f529a01c
      antirez authored
      MOVE was not able to move the TTL: when a key was moved into a different
      database number, it became persistent like if PERSIST was used.
      
      In some incredible way (I guess almost nobody uses Redis MOVE) this bug
      remained unnoticed inside Redis internals for many years.
      Finally Andy Grunwald discovered it and opened an issue.
      
      This commit fixes the bug and adds a regression test.
      
      Close #2765.
      f529a01c
  11. 08 Sep, 2015 2 commits
  12. 07 Sep, 2015 1 commit
    • antirez's avatar
      Undo slaves state change on failed rdbSaveToSlavesSockets(). · 8e555374
      antirez authored
      As Oran Agra suggested, in startBgsaveForReplication() when the BGSAVE
      attempt returns an error, we scan the list of slaves in order to remove
      them since there is no way to serve them currently.
      
      However we check for the replication state BGSAVE_START, which was
      modified by rdbSaveToSlaveSockets() before forking(). So when fork fails
      the state of slaves remain BGSAVE_END and no cleanup is performed.
      
      This commit fixes the problem by making rdbSaveToSlavesSockets() able to
      undo the state change on fork failure.
      8e555374