1. 05 Nov, 2013 5 commits
    • antirez's avatar
      SCAN code refactored to parse cursor first. · 060d56e7
      antirez authored
      The previous implementation of SCAN parsed the cursor in the generic
      function implementing SCAN, SSCAN, HSCAN and ZSCAN.
      
      The actual higher-level command implementation only checked for empty
      keys and return ASAP in that case. The result was that inverting the
      arguments of, for instance, SSCAN for example and write:
      
          SSCAN 0 key
      
      Instead of
      
          SSCAN key 0
      
      Resulted into no error, since 0 is a non-existing key name very likely.
      Just the iterator returned no elements at all.
      
      In order to fix this issue the code was refactored to extract the
      function to parse the cursor and return the error. Every higher level
      command implementation now parses the cursor and later checks if the key
      exist or not.
      060d56e7
    • antirez's avatar
      SCAN: when iterating ziplists or intsets always return cursor of 0. · 162acd8a
      antirez authored
      The previous implementation assumed that the first call always happens
      with cursor set to 0, this may not be the case, and we want to return 0
      anyway otherwise the (broken) client code will loop forever.
      162acd8a
    • antirez's avatar
      406be0ea
    • antirez's avatar
      HSCAN/ZSCAN: skip value when matching. · 54a5a7df
      antirez authored
      This fixes issue #1360 and #1362.
      54a5a7df
    • antirez's avatar
      bebbc7f9
  2. 31 Oct, 2013 3 commits
  3. 29 Oct, 2013 13 commits
  4. 27 Jun, 2013 1 commit
  5. 28 Mar, 2013 1 commit
  6. 26 Mar, 2013 1 commit
    • antirez's avatar
      TTL / PTTL commands: two bugs fixed. · a452b548
      antirez authored
      This commit fixes two corner cases for the TTL command.
      
      1) When the key was already logically expired (expire time older
      than current time) the command returned -1 instead of -2.
      
      2) When the key was existing and the expire was found to be exactly 0
      (the key was just about to expire), the command reported -1 (that is, no
      expire) instead of a TTL of zero (that is, about to expire).
      a452b548
  7. 12 Feb, 2013 1 commit
  8. 28 Jan, 2013 5 commits
  9. 19 Jan, 2013 2 commits
    • antirez's avatar
      Whitelist SIGUSR1 to avoid auto-triggering errors. · 39f0a33f
      antirez authored
      This commit fixes issue #875 that was caused by the following events:
      
      1) There is an active child doing BGSAVE.
      2) flushall is called (or any other condition that makes Redis killing
      the saving child process).
      3) An error is sensed by Redis as the child exited with an error (killed
      by a singal), that stops accepting write commands until a BGSAVE happens
      to be executed with success.
      
      Whitelisting SIGUSR1 and making sure Redis always uses this signal in
      order to kill its own children fixes the issue.
      39f0a33f
    • guiquanz's avatar
      Fixed many typos. · 1caf0939
      guiquanz authored
      Conflicts fixed, mainly because 2.8 has no cluster support / files:
      	00-RELEASENOTES
      	src/cluster.c
      	src/crc16.c
      	src/redis-trib.rb
      	src/redis.h
      1caf0939
  10. 12 Nov, 2012 1 commit
    • antirez's avatar
      TTL API change: TTL returns -2 for non existing keys. · 50c41de7
      antirez authored
      The previous behavior was to return -1 if:
      
      1) Existing key but without an expire set.
      2) Non existing key.
      
      Now the second case is handled in a different, and TTL will return -2
      if the key does not exist at all.
      
      PTTL follows the same behavior as well.
      50c41de7
  11. 08 Nov, 2012 1 commit
  12. 11 Sep, 2012 1 commit
    • antirez's avatar
      Make sure that SELECT argument is an integer or return an error. · b58f03a0
      antirez authored
      Unfortunately we had still the lame atoi() without any error checking in
      place, so "SELECT foo" would work as "SELECT 0". This was not an huge
      problem per se but some people expected that DB can be strings and not
      just numbers, and without errors you get the feeling that they can be
      numbers, but not the behavior.
      
      Now getLongFromObjectOrReply() is used as almost everybody else across
      the code, generating an error if the number is not an integer or
      overflows the long type.
      
      Thanks to @mipearson for reporting that on Twitter.
      b58f03a0
  13. 30 Apr, 2012 1 commit
    • Pieter Noordhuis's avatar
      Use safe dictionary iterator from KEYS · 9311d2b5
      Pieter Noordhuis authored
      Every matched key in a KEYS call is checked for expiration. When the key
      is set to expire, the call to `getExpire` will assert that the key also
      exists in the main dictionary. This in turn causes a rehashing step to
      be executed. Rehashing a dictionary when there is an iterator active may
      result in the iterator emitting duplicate entries, or not emitting some
      entries at all. By using a safe iterator, the rehash step is omitted.
      9311d2b5
  14. 07 Apr, 2012 1 commit
  15. 05 Apr, 2012 3 commits