1. 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
  2. 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
  3. 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
  4. 23 Apr, 2012 1 commit
  5. 13 Apr, 2012 6 commits
  6. 29 Mar, 2012 1 commit
  7. 28 Mar, 2012 1 commit
  8. 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
  9. 24 Feb, 2012 1 commit
  10. 13 Feb, 2012 1 commit
  11. 02 Feb, 2012 1 commit
  12. 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
  13. 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
  14. 29 Jan, 2012 1 commit
  15. 18 Nov, 2011 1 commit
  16. 27 Oct, 2011 1 commit
  17. 25 Oct, 2011 4 commits
  18. 24 Oct, 2011 1 commit
  19. 20 Oct, 2011 1 commit
  20. 19 Oct, 2011 1 commit
  21. 04 Oct, 2011 1 commit
  22. 27 Sep, 2011 3 commits
  23. 23 Sep, 2011 1 commit
  24. 13 Jul, 2011 1 commit
  25. 25 May, 2011 5 commits