- 15 11月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
A few people have written custom C commands because bit manipulation isn't exposed through Lua. Let's give them Mike Pall's bitop. This adds bitop 1.0.2 (2012-05-08) from http://bitop.luajit.org/ bitop is imported as "bit" into the global namespace. New Lua commands: bit.tobit, bit.tohex, bit.bnot, bit.band, bit.bor, bit.bxor, bit.lshift, bit.rshift, bit.arshift, bit.rol, bit.ror, bit.bswap Verification of working (the asserts would abort on error, so (nil) is correct): 127.0.0.1:6379> eval "assert(bit.tobit(1) == 1); assert(bit.band(1) == 1); assert(bit.bxor(1,2) == 3); assert(bit.bor(1,2,4,8,16,32,64,128) == 255)" 0 (nil) 127.0.0.1:6379> eval 'assert(0x7fffffff == 2147483647, "broken hex literals"); assert(0xffffffff == -1 or 0xffffffff == 2^32-1, "broken hex literals"); assert(tostring(-1) == "-1", "broken tostring()"); assert(tostring(0xffffffff) == "-1" or tostring(0xffffffff) == "4294967295", "broken tostring()")' 0 (nil) Tests also integrated into the scripting tests and can be run with: ./runtest --single unit/scripting Tests are excerpted from `bittest.lua` included in the bitop distribution.
-
- 01 9月, 2014 1 次提交
-
-
由 Paddy Byers 提交于
-
- 27 8月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Negative key count causes segfault in Lua functions. Fixes #1842 Closes #1843
-
- 16 6月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Lua scripts are executed in the context of the currently selected database (as selected by the caller of the script). However Lua scripts are also free to use the SELECT command in order to affect other DBs. When SELECT is called frm Lua, the old behavior, before this commit, was to automatically set the Lua caller selected DB to the last DB selected by Lua. See for example the following sequence of commands: SELECT 0 SET x 10 EVAL "redis.call('select','1')" 0 SET x 20 Before this commit after the execution of this sequence of commands, we'll have x=10 in DB 0, and x=20 in DB 1. Because of the problem above, there was a bug affecting replication of Lua scripts, because of the actual implementation of replication. It was possible to fix the implementation of Lua scripts in order to fix the issue, but looking closely, the bug is the consequence of the behavior of Lua ability to set the caller's DB. Under the old semantics, a script selecting a different DB, has no simple ways to restore the state and select back the previously selected DB. Moreover the script auhtor must remember that the restore is needed, otherwise the new commands executed by the caller, will be executed in the context of a different DB. So this commit fixes both the replication issue, and this hard-to-use semantics, by removing the ability of Lua, after the script execution, to force the caller to switch to the DB selected by the Lua script. The new behavior of the previous sequence of commadns is to just set X=20 in DB 0. However Lua scripts are still capable of writing / reading from different DBs if needed. WARNING: This is a semantical change that will break programs that are conceived to select the client selected DB via Lua scripts. This fixes issue #1811.
-
- 11 6月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
The new check-for-number behavior of Lua arguments broke users who use large strings of just integers. The Lua number check would convert the string to a number, but that breaks user data because Lua numbers have limited precision compared to an arbitrarily precise number wrapped in a string. Regression fixed and new test added. Fixes #1118 again.
-
- 06 6月, 2014 1 次提交
-
-
由 yoav 提交于
-
- 05 6月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 22 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 20 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 07 5月, 2014 1 次提交
-
-
由 antirez 提交于
SPOP, tested in the new test, is among the commands rewritng the client->argv argument vector (it gets rewritten as SREM) for command replication purposes. Because of recent optimizations to client->argv caching in the context of the Lua internal Redis client, it is important to test for SPOP to be callable from Lua without bad effects to the other commands.
-
- 13 2月, 2014 1 次提交
-
-
由 antirez 提交于
It was verified that reverting the commit that fixes the bug, the test no longer passes.
-
- 30 8月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 20 6月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 19 1月, 2013 1 次提交
-
-
由 guiquanz 提交于
Conflicts fixed, mainly because 2.8 has no cluster support / files: 00-RELEASENOTES src/cluster.c src/crc16.c src/redis-trib.rb src/redis.h
-
- 10 1月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 22 11月, 2012 1 次提交
-
-
由 antirez 提交于
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.
-
- 22 10月, 2012 1 次提交
-
-
由 antirez 提交于
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.
-
- 01 10月, 2012 1 次提交
-
- 28 9月, 2012 1 次提交
-
-
由 antirez 提交于
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
-
- 17 9月, 2012 1 次提交
-
-
由 antirez 提交于
Redis provides support for blocking operations such as BLPOP or BRPOP. This operations are identical to normal LPOP and RPOP operations as long as there are elements in the target list, but if the list is empty they block waiting for new data to arrive to the list. All the clients blocked waiting for th same list are served in a FIFO way, so the first that blocked is the first to be served when there is more data pushed by another client into the list. The previous implementation of blocking operations was conceived to serve clients in the context of push operations. For for instance: 1) There is a client "A" blocked on list "foo". 2) The client "B" performs `LPUSH foo somevalue`. 3) The client "A" is served in the context of the "B" LPUSH, synchronously. Processing things in a synchronous way was useful as if "A" pushes a value that is served by "B", from the point of view of the database is a NOP (no operation) thing, that is, nothing is replicated, nothing is written in the AOF file, and so forth. However later we implemented two things: 1) Variadic LPUSH that could add multiple values to a list in the context of a single call. 2) BRPOPLPUSH that was a version of BRPOP that also provided a "PUSH" side effect when receiving data. This forced us to make the synchronous implementation more complex. If client "B" is waiting for data, and "A" pushes three elemnents in a single call, we needed to propagate an LPUSH with a missing argument in the AOF and replication link. We also needed to make sure to replicate the LPUSH side of BRPOPLPUSH, but only if in turn did not happened to serve another blocking client into another list ;) This were complex but with a few of mutually recursive functions everything worked as expected... until one day we introduced scripting in Redis. Scripting + synchronous blocking operations = Issue #614. Basically you can't "rewrite" a script to have just a partial effect on the replicas and AOF file if the script happened to serve a few blocked clients. The solution to all this problems, implemented by this commit, is to change the way we serve blocked clients. Instead of serving the blocked clients synchronously, in the context of the command performing the PUSH operation, it is now an asynchronous and iterative process: 1) If a key that has clients blocked waiting for data is the subject of a list push operation, We simply mark keys as "ready" and put it into a queue. 2) Every command pushing stuff on lists, as a variadic LPUSH, a script, or whatever it is, is replicated verbatim without any rewriting. 3) Every time a Redis command, a MULTI/EXEC block, or a script, completed its execution, we run the list of keys ready to serve blocked clients (as more data arrived), and process this list serving the blocked clients. 4) As a result of "3" maybe more keys are ready again for other clients (as a result of BRPOPLPUSH we may have push operations), so we iterate back to step "3" if it's needed. The new code has a much simpler semantics, and a simpler to understand implementation, with the disadvantage of not being able to "optmize out" a PUSH+BPOP as a No OP. This commit will be tested with care before the final merge, more tests will be added likely.
-
- 05 9月, 2012 1 次提交
-
-
由 antirez 提交于
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 ;)
-
- 31 8月, 2012 1 次提交
-
-
由 antirez 提交于
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.
-
- 03 6月, 2012 1 次提交
-
-
由 antirez 提交于
wait_for_condition is now used instead of the usual "after 1000" (that is the way to sleep in Tcl). This should avoid to find the replica in a state where it is loading the RDB in memory, returning -LOADING error. This test used to fail when running the test over valgrind, due to the added latencies.
-
- 27 4月, 2012 1 次提交
-
-
由 antirez 提交于
A new primitive wait_for_condition was introduced in the scripting engine that makes waiting for events simpler, so that it is simpler to write tests that are more resistant to timing issues.
-
- 20 4月, 2012 1 次提交
-
-
由 antirez 提交于
-
- 19 4月, 2012 1 次提交
-
-
由 antirez 提交于
-
- 13 4月, 2012 3 次提交
- 29 3月, 2012 1 次提交
-
-
由 antirez 提交于
-
- 02 2月, 2012 1 次提交
-
-
由 antirez 提交于
Added tests checking ability of the scripting engine to reorder the output of commands with a random output regarding signle elements position in the multi bulk reply.
-
- 31 10月, 2011 1 次提交
-
-
由 antirez 提交于
-
- 25 10月, 2011 2 次提交
- 20 10月, 2011 1 次提交
-
-
由 antirez 提交于
Redis.call is now split into two variants of the same function. Redis.call will raise an error by default. Redis.pcall will return the error object instead.
-
- 27 9月, 2011 1 次提交
-
-
由 antirez 提交于
-
- 16 7月, 2011 1 次提交
-
-
由 antirez 提交于
-
- 15 7月, 2011 1 次提交
-
-
由 antirez 提交于
-
- 25 5月, 2011 1 次提交
-
-
由 antirez 提交于
-