1. 09 Apr, 2018 3 commits
  2. 05 Apr, 2018 1 commit
  3. 01 Apr, 2018 2 commits
  4. 31 Mar, 2018 2 commits
  5. 30 Mar, 2018 9 commits
  6. 29 Mar, 2018 1 commit
  7. 01 Mar, 2018 1 commit
  8. 15 Feb, 2018 1 commit
  9. 14 Feb, 2018 5 commits
  10. 07 Jan, 2018 1 commit
  11. 29 Dec, 2017 1 commit
    • Oran Agra's avatar
      fix processing of large bulks (above 2GB) · 60a4f12f
      Oran Agra authored
      - protocol parsing (processMultibulkBuffer) was limitted to 32big positions in the buffer
        readQueryFromClient potential overflow
      - rioWriteBulkCount used int, although rioWriteBulkString gave it size_t
      - several places in sds.c that used int for string length or index.
      - bugfix in RM_SaveAuxField (return was 1 or -1 and not length)
      - RM_SaveStringBuffer was limitted to 32bit length
      60a4f12f
  12. 24 Nov, 2017 1 commit
  13. 23 Nov, 2017 1 commit
  14. 22 Nov, 2017 1 commit
  15. 28 Sep, 2017 3 commits
  16. 27 Sep, 2017 3 commits
  17. 23 Jul, 2017 2 commits
    • antirez's avatar
      Modules: don't crash when Lua calls a module blocking command. · 31404355
      antirez authored
      Lua scripting does not support calling blocking commands, however all
      the native Redis commands are flagged as "s" (no scripting flag), so
      this is not possible at all. With modules there is no such mechanism in
      order to flag a command as non callable by the Lua scripting engine,
      moreover we cannot trust the modules users from complying all the times:
      it is likely that modules will be released to have blocking commands
      without such commands being flagged correctly, even if we provide a way to
      signal this fact.
      
      This commit attempts to address the problem in a short term way, by
      detecting that a module is trying to block in the context of the Lua
      scripting engine client, and preventing to do this. The module will
      actually believe to block as usually, but what happens is that the Lua
      script receives an error immediately, and the background call is ignored
      by the Redis engine (if not for the cleanup callbacks, once it
      unblocks).
      
      Long term, the more likely solution, is to introduce a new call called
      RedisModule_GetClientFlags(), so that a command can detect if the caller
      is a Lua script, and return an error, or avoid blocking at all.
      
      Being the blocking API experimental right now, more work is needed in
      this regard in order to reach a level well blocking module commands and
      all the other Redis subsystems interact peacefully.
      
      Now the effect is like the following:
      
          127.0.0.1:6379> eval "redis.call('hello.block',1,5000)" 0
          (error) ERR Error running script (call to
          f_b5ba35ff97bc1ef23debc4d6e9fd802da187ed53): @user_script:1: ERR
          Blocking module command called from Lua script
      
      This commit fixes issue #4127 in the short term.
      31404355
    • antirez's avatar
      5bfdfbe1
  18. 20 Jul, 2017 1 commit
    • antirez's avatar
      Fix two bugs in moduleTypeLookupModuleByID(). · b1c2e1a1
      antirez authored
      The function cache was not working at all, and the function returned
      wrong values if there where two or more modules exporting native data
      types.
      
      See issue #4131 for more details.
      b1c2e1a1
  19. 14 Jul, 2017 1 commit