- 09 Apr, 2018 3 commits
-
-
antirez authored
Plus freeMemoryIfNeeded() refactoring to improve legibility. Please review this commit for sanity.
-
antirez authored
-
antirez authored
Note that this was an experimental API that can only be enabled with REIDSMODULE_EXPERIMENTAL_API, so it is subject to change until its promoted to stable API. Sorry for the breakage, it is trivial to resolve btw. This change will not be back ported to Redis 4.0.
-
- 05 Apr, 2018 1 commit
-
-
antirez authored
-
- 01 Apr, 2018 2 commits
- 31 Mar, 2018 2 commits
- 30 Mar, 2018 9 commits
- 29 Mar, 2018 1 commit
-
-
antirez authored
-
- 01 Mar, 2018 1 commit
-
-
charsyam authored
-
- 15 Feb, 2018 1 commit
-
-
antirez authored
-
- 14 Feb, 2018 5 commits
- 07 Jan, 2018 1 commit
-
-
Dvir Volk authored
-
- 29 Dec, 2017 1 commit
-
-
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
-
- 24 Nov, 2017 1 commit
-
-
antirez authored
-
- 23 Nov, 2017 1 commit
-
-
antirez authored
See issue #4466 / #4467.
-
- 22 Nov, 2017 1 commit
-
-
Yossi Gottlieb authored
For example: 1. A module command called within a MULTI section. 2. A Lua script with replicate_commands() called within a MULTI section. 3. A module command called from a Lua script in the above context.
-
- 28 Sep, 2017 3 commits
-
-
antirez authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 27 Sep, 2017 3 commits
- 23 Jul, 2017 2 commits
-
-
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.
-
antirez authored
-
- 20 Jul, 2017 1 commit
-
-
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.
-
- 14 Jul, 2017 1 commit
-
-
antirez authored
Before this fix the DB currenty selected by the client blocked was not respected and operations were always performed on DB 0.
-