- 29 Sep, 2014 1 commit
-
-
Matt Stancliff authored
-
- 01 Sep, 2014 1 commit
-
-
Paddy Byers authored
-
- 08 Aug, 2014 2 commits
-
-
Matt Stancliff authored
Previously, "MOVE key somestring" would move the key to DB 0 which is just unexpected and wrong. String as DB == error. Test added too. Modified by @antirez in order to use the getLongLongFromObject() API instead of strtol(). Fixes #1428
-
Matt Stancliff authored
Also adds test for numsub — due to tcl being tcl, it doesn't capture the "numberness" of the fix, but now we at least have one test case for numsub. Closes #1561
-
- 07 Aug, 2014 3 commits
-
-
Matt Stancliff authored
We only want to use the last STORE key, but we have to record we actually found a STORE key so we can increment the final return key count. Test added to prevent further regression. Closes #1883, #1645, #1647
-
Jan-Erik Rediger authored
Previously the end was casted to a smaller type which resulted in a wrong check and failed with values larger than handled by unsigned. Closes #1847, #1844
-
Matt Stancliff authored
Negative key count causes segfault in Lua functions. Fixes #1842 Closes #1843
-
- 22 Jul, 2014 1 commit
-
-
antirez authored
This is not a regression but issue #1786 showed the need for this test.
-
- 18 Jul, 2014 2 commits
- 10 Jul, 2014 3 commits
- 18 Jun, 2014 1 commit
-
-
antirez authored
-
- 12 Jun, 2014 2 commits
-
-
antirez authored
-
antirez authored
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.
-
- 10 Jun, 2014 1 commit
-
-
Matt Stancliff authored
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.
-
- 04 Jun, 2014 1 commit
-
-
antirez authored
-
- 22 May, 2014 1 commit
-
-
antirez authored
-
- 21 May, 2014 1 commit
-
-
Matt Stancliff authored
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
-
- 20 May, 2014 1 commit
-
-
antirez authored
-
- 19 May, 2014 1 commit
-
-
antirez authored
-
- 07 May, 2014 1 commit
-
-
antirez authored
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.
-
- 24 Apr, 2014 1 commit
-
-
antirez authored
-
- 18 Apr, 2014 2 commits
- 17 Apr, 2014 1 commit
-
-
antirez authored
-
- 16 Apr, 2014 2 commits
- 14 Apr, 2014 1 commit
-
-
antirez authored
-
- 10 Apr, 2014 1 commit
-
-
Matt Stancliff authored
Verify proper expire-before-delete behavior. This test passes with the expire-before-delete commit and fails without it.
-
- 06 Apr, 2014 1 commit
-
-
yoav authored
-
- 03 Apr, 2014 1 commit
-
-
antirez authored
-
- 27 Feb, 2014 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
It was verified in practice that this test is able to stress much more the implementation by introducing errors that were only trivially to detect with different offsets but impossible to detect starting always at zero and counting bits the full length of the string.
-
- 13 Feb, 2014 1 commit
-
-
antirez authored
It was verified that reverting the commit that fixes the bug, the test no longer passes.
-
- 09 Jan, 2014 1 commit
-
-
antirez authored
-
- 08 Jan, 2014 1 commit
-
-
antirez authored
-