- 30 Mar, 2018 2 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 2 commits
- 11 Jul, 2017 1 commit
-
-
antirez authored
See issue #3844 for more information.
-
- 10 Jul, 2017 1 commit
-
-
Guy Benoish authored
-
- 06 Jul, 2017 1 commit
-
-
antirez authored
-
- 05 Jul, 2017 1 commit
-
-
antirez authored
They are technically like commands executed from external clients one after the other, and do not constitute a single atomic entity.
-
- 03 Jul, 2017 1 commit
-
-
Dvir Volk authored
-
- 27 Jun, 2017 1 commit
-
-
antirez authored
The original RDB serialization format was not parsable without the module loaded, becuase the structure was managed only by the module itself. Moreover RDB is a streaming protocol in the sense that it is both produce di an append-only fashion, and is also sometimes directly sent to the socket (in the case of diskless replication). The fact that modules values cannot be parsed without the relevant module loaded is a problem in many ways: RDB checking tools must have loaded modules even for doing things not involving the value at all, like splitting an RDB into N RDBs by key or alike, or just checking the RDB for sanity. In theory module values could be just a blob of data with a prefixed length in order for us to be able to skip it. However prefixing the values with a length would mean one of the following: 1. To be able to write some data at a previous offset. This breaks stremaing. 2. To bufferize values before outputting them. This breaks performances. 3. To have some chunked RDB output format. This breaks simplicity. Moreover, the above solution, still makes module values a totally opaque matter, with the fowllowing problems: 1. The RDB check tool can just skip the value without being able to at least check the general structure. For datasets composed mostly of modules values this means to just check the outer level of the RDB not actually doing any checko on most of the data itself. 2. It is not possible to do any recovering or processing of data for which a module no longer exists in the future, or is unknown. So this commit implements a different solution. The modules RDB serialization API is composed if well defined calls to store integers, floats, doubles or strings. After this commit, the parts generated by the module API have a one-byte prefix for each of the above emitted parts, and there is a final EOF byte as well. So even if we don't know exactly how to interpret a module value, we can always parse it at an high level, check the overall structure, understand the types used to store the information, and easily skip the whole value. The change is backward compatible: older RDB files can be still loaded since the new encoding has a new RDB type: MODULE_2 (of value 7). The commit also implements the ability to check RDB files for sanity taking advantage of the new feature.
-
- 03 May, 2017 3 commits
- 02 May, 2017 3 commits
- 28 Apr, 2017 1 commit
-
-
antirez authored
-
- 10 Apr, 2017 1 commit
-
-
antirez authored
-