- 18 6月, 2014 2 次提交
-
-
由 antirez 提交于
Functionally the same, but makes cherry picking simpler.
-
由 Matt Stancliff 提交于
(Note from @antirez: modified to apply to 2.8)
-
- 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.
-
- 09 6月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Behrad Zari discovered [1] and Josiah reported [2]: if you block and wait for a list to exist, but the list creates from a non-push command, the blocked client never gets notified. This commit adds notification of blocked clients into the DB layer and away from individual commands. Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE, and RESTORE. Previously, blocked client notifications were only triggered by [LR]PUSH. Your client would never get notified if a list were created by SORT..STORE or RENAME or a RESTORE, etc. Blocked client notification now happens in one unified place: - dbAdd() triggers notification when adding a list to the DB Two new tests are added that fail prior to this commit. All test pass. Fixes #1668 [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU [2]: #1668
-
- 06 6月, 2014 1 次提交
-
-
由 yoav 提交于
-
- 05 6月, 2014 2 次提交
- 22 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 20 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 19 5月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 07 5月, 2014 2 次提交
-
-
由 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.
-
由 antirez 提交于
Sometimes the process is still there but no longer in a state that can be checked (after being killed). This used to happen after a call to SHUTDOWN NOSAVE in the scripting unit, causing a false positive.
-
- 23 4月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Verify proper expire-before-delete behavior. This test passes with the expire-before-delete commit and fails without it.
-
- 18 4月, 2014 3 次提交
- 17 4月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 16 4月, 2014 3 次提交
- 25 3月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 21 3月, 2014 3 次提交
- 05 3月, 2014 11 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
This commit sets the failover timeout to 30 seconds instead of the 180 seconds default, and allows to reconfigure multiple slaves at the same time. This makes tests less sensible to timing, with the result that there are less false positives due to normal behaviors that require time to succeed or to be retried. However the long term solution is probably some way in order to detect when a test failed because of timing issues (for example split brain during leader election) and retry it.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
- 27 2月, 2014 3 次提交