1. 25 Jun, 2013 2 commits
  2. 24 Jun, 2013 2 commits
  3. 21 Jun, 2013 1 commit
    • antirez's avatar
      New API to force propagation. · 515a26bb
      antirez authored
      The old REDIS_CMD_FORCE_REPLICATION flag was removed from the
      implementation of Redis, now there is a new API to force specific
      executions of a command to be propagated to AOF / Replication link:
      
          void forceCommandPropagation(int flags);
      
      The new API is also compatible with Lua scripting, so a script that will
      execute commands that are forced to be propagated, will also be
      propagated itself accordingly even if no change to data is operated.
      
      As a side effect, this new design fixes the issue with scripts not able
      to propagate PUBLISH to slaves (issue #873).
      515a26bb
  4. 19 Jun, 2013 1 commit
  5. 18 Jun, 2013 2 commits
  6. 22 May, 2013 1 commit
  7. 19 Jan, 2013 1 commit
  8. 10 Jan, 2013 1 commit
    • antirez's avatar
      Multiple fixes for EVAL (issue #872). · baee5650
      antirez authored
      1) The event handler was no restored after a timeout condition if the
         command was eventually executed with success.
      2) The command was not converted to EVAL in case of errors in the middle
         of the execution.
      3) Terrible duplication of code without any apparent reason.
      baee5650
  9. 22 Nov, 2012 1 commit
    • antirez's avatar
      EVALSHA is now case insensitive. · 95f68f7b
      antirez authored
      EVALSHA used to crash if the SHA1 was not lowercase (Issue #783).
      Fixed using a case insensitive dictionary type for the sha -> script
      map used for replication of scripts.
      95f68f7b
  10. 08 Nov, 2012 1 commit
  11. 22 Oct, 2012 1 commit
    • antirez's avatar
      Differentiate SCRIPT KILL error replies. · acfe3675
      antirez authored
      When calling SCRIPT KILL currently you can get two errors:
      
      * No script in timeout (busy) state.
      * The script already performed a write.
      
      It is useful to be able to distinguish the two errors, but right now both
      start with "ERR" prefix, so string matching (that is fragile) must be used.
      
      This commit introduces two different prefixes.
      
      -NOTBUSY and -UNKILLABLE respectively to reply with an error when no
      script is busy at the moment, and when the script already executed a
      write operation and can not be killed.
      acfe3675
  12. 01 Oct, 2012 1 commit
  13. 28 Sep, 2012 2 commits
    • antirez's avatar
      Scripting: add helper functions redis.error_reply() and redis.status_reply(). · 9c21b72b
      antirez authored
      A previous commit introduced Redis.NIL. This commit adds similar helper
      functions to return tables with a single field set to the specified
      string so that instead of using 'return {err="My Error"}' it is possible
      to use a more idiomatic form:
      
          return redis.error_reply("My Error")
          return redis.status_reply("OK")
      9c21b72b
    • antirez's avatar
      Scripting: redis.NIL to return nil bulk replies. · 6dd1693c
      antirez authored
      Lua arrays can't contain nil elements (see
      http://www.lua.org/pil/19.1.html for more information), so Lua scripts
      were not able to return a multi-bulk reply containing nil bulk
      elements inside.
      
      This commit introduces a special conversion: a table with just
      a "nilbulk" field set to a boolean value is converted by Redis as a nil
      bulk reply, but at the same time for Lua this type is not a "nil" so can
      be used inside Lua arrays.
      
      This type is also assigned to redis.NIL, so the following two forms
      are equivalent and will be able to return a nil bulk reply as second
      element of a three elements array:
      
          EVAL "return {1,redis.NIL,3}" 0
          EVAL "return {1,{nilbulk=true},3}" 0
      
      The result in redis-cli will be:
      
          1) (integer) 1
          2) (nil)
          3) (integer) 3
      6dd1693c
  14. 04 Sep, 2012 1 commit
    • antirez's avatar
      Scripting: Force SORT BY constant determinism inside SORT itself. · 36741b2c
      antirez authored
      SORT is able to return (faster than when ordering) unordered output if
      the "BY" clause is used with a constant value. However we try to play
      well with scripting requirements of determinism providing always sorted
      outputs when SORT (and other similar commands) are called by Lua
      scripts.
      
      However we used the general mechanism in place in scripting in order to
      reorder SORT output, that is, if the command has the "S" flag set, the
      Lua scripting engine will take an additional step when converting a
      multi bulk reply to Lua value, calling a Lua sorting function.
      
      This is suboptimal as we can do it faster inside SORT itself.
      This is also broken as issue #545 shows us: basically when SORT is used
      with a constant BY, and additionally also GET is used, the Lua scripting
      engine was trying to order the output as a flat array, while it was
      actually a list of key-value pairs.
      
      What we do know is to recognized if the caller of SORT is the Lua client
      (since we can check this using the REDIS_LUA_CLIENT flag). If so, and if
      a "don't sort" condition is triggered by the BY option with a constant
      string, we force the lexicographical sorting.
      
      This commit fixes this bug and improves the performance, and at the same
      time simplifies the implementation. This does not mean I'm smart today,
      it means I was stupid when I committed the original implementation ;)
      36741b2c
  15. 31 Aug, 2012 2 commits
    • antirez's avatar
      Scripting: Reset Lua fake client reply_bytes after command execution. · e323635c
      antirez authored
      Lua scripting uses a fake client in order to run commands in the context
      of a client, accumulate the reply, and convert it into a Lua object
      to return to the caller. This client is reused again and again, and is
      referenced by the server.lua_client globally accessible pointer.
      
      However after every call to redis.call() or redis.pcall(), that is
      handled by the luaRedisGenericCommand() function, the reply_bytes field
      of the client was not set back to zero. This filed is used to estimate
      the amount of memory currently used in the reply. Because of the lack of
      reset, script after script executed, this value used to get bigger and
      bigger, and in the end on 32 bit systems it triggered the following
      assert:
      
          redisAssert(c->reply_bytes < ULONG_MAX-(1024*64));
      
      On 64 bit systems this does not happen because it takes too much time to
      reach values near to 2^64 for users to see the practical effect of the
      bug.
      
      Now in the cleanup stage of luaRedisGenericCommand() we reset the
      reply_bytes counter to zero, avoiding the issue. It is not practical to
      add a test for this bug, but the fix was manually tested using a
      debugger.
      
      This commit fixes issue #656.
      e323635c
    • antirez's avatar
      Scripting: require at least one argument for redis.call(). · 46c31a15
      antirez authored
      Redis used to crash with a call like the following:
      
          EVAL "redis.call()" 0
      
      Now the explicit check for at least one argument prevents the problem.
      
      This commit fixes issue #655.
      46c31a15
  16. 27 Apr, 2012 1 commit
    • antirez's avatar
      Set LUA_MASKCOUNT hook more selectively. Fixes issue #480. · 0ad10db2
      antirez authored
      An user reported a crash with Redis scripting (see issue #480 on
      github), inspection of the kindly provided strack trace showed that
      server.lua_caller was probably set to NULL. The stack trace also slowed
      that the call to the hook was originating from a point where we just
      used to set/get a few global variables in the Lua state.
      
      What was happening is that we did not set the timeout hook selectively
      only when the user script was called. Now we set it more selectively,
      specifically only in the context of the lua_pcall() call, and make sure
      to remove the hook when the call returns. Otherwise the hook can get
      called in random contexts every time we do something with the Lua
      state.
      0ad10db2
  17. 23 Apr, 2012 1 commit
  18. 13 Apr, 2012 6 commits
  19. 29 Mar, 2012 1 commit
  20. 28 Mar, 2012 1 commit
  21. 20 Mar, 2012 1 commit
    • antirez's avatar
      Support for read-only slaves. Semantical fixes. · f3fd419f
      antirez authored
      This commit introduces support for read only slaves via redis.conf and CONFIG GET/SET commands. Also various semantical fixes are implemented here:
      
      1) MULTI/EXEC with only read commands now work where the server is into a state where writes (or commands increasing memory usage) are not allowed. Before this patch everything inside a transaction would fail in this conditions.
      
      2) Scripts just calling read-only commands will work against read only
      slaves, when the server is out of memory, or when persistence is into an
      error condition. Before the patch EVAL always failed in this condition.
      f3fd419f
  22. 24 Feb, 2012 1 commit
  23. 13 Feb, 2012 1 commit
  24. 02 Feb, 2012 1 commit
  25. 01 Feb, 2012 1 commit
    • antirez's avatar
      SORT is now more deterministic: does not accept to compare by score items that... · 2c861050
      antirez authored
      SORT is now more deterministic: does not accept to compare by score items that have scores not representing a valid double. Also items with the same score are compared lexycographically. At the same time the scripting side introduced the ability to sort the output of SORT when sort uses the BY <constant> optimization, resulting in no specific ordering. Since in this case the user may use GET, and the result of GET can be null, converted into false as Lua data type, this commit also introduces the ability to sort Lua tables containining false, only if the first (faster) attempt at using just table.sort with a single argument fails.
      2c861050
  26. 31 Jan, 2012 1 commit
    • antirez's avatar
      Order output of commands returning random arrays using table.sort when called... · 548efd91
      antirez authored
      Order output of commands returning random arrays using table.sort when called from Lua, partially fixing issue #165. The issue is yet not completely fixed since we can't add the REDIS_CMD_SORT_FOR_SCRIPT flag in SORT currently, both because it may contain NULLs and because it is not cool to re-sort everything at every call when instead this should be sorted only if BY <constant> is used.
      548efd91
  27. 29 Jan, 2012 1 commit
  28. 18 Nov, 2011 1 commit
  29. 27 Oct, 2011 1 commit
  30. 25 Oct, 2011 1 commit