- 10 May, 2016 1 commit
-
-
antirez authored
-
- 25 Apr, 2016 1 commit
-
-
Oran Agra authored
-
- 11 Dec, 2015 1 commit
-
-
antirez authored
-
- 02 Oct, 2015 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 8 commits
- 14 Sep, 2015 2 commits
-
-
antirez authored
getExpire() returns -1 when no expire exists. Related to #2765.
-
antirez authored
MOVE was not able to move the TTL: when a key was moved into a different database number, it became persistent like if PERSIST was used. In some incredible way (I guess almost nobody uses Redis MOVE) this bug remained unnoticed inside Redis internals for many years. Finally Andy Grunwald discovered it and opened an issue. This commit fixes the bug and adds a regression test. Close #2765.
-
- 27 Jul, 2015 1 commit
-
-
antirez authored
-
- 26 Jul, 2015 5 commits
- 13 Jul, 2015 1 commit
-
-
antirez authored
The new return value is the number of keys existing, among the ones specified in the command line, counting the same key multiple times if given multiple times (and if it exists). See PR #2667.
-
- 23 Feb, 2015 1 commit
-
-
antirez authored
Fixes issue #2392.
-
- 12 Dec, 2014 1 commit
-
-
clark.kang authored
-
- 10 Dec, 2014 1 commit
-
-
antirez authored
Slaves key expire is orchestrated by the master. Sometimes the master will send the synthesized DEL to expire keys on the slave with a non trivial delay (when the key is not accessed, only the incremental expiry algorithm will expire it in background). During that time, a key is logically expired, but slaves still return the key if you GET (or whatever) it. This is a bad behavior. However we can't simply trust the slave view of the key, since we need the master to be able to send write commands to update the slave data set, and DELs should only happen when the key is expired in the master in order to ensure consistency. However 99.99% of the issues with this behavior is when a client which is not a master sends a read only command. In this case we are safe and can consider the key as non existing. This commit does a few changes in order to make this sane: 1. lookupKeyRead() is modified in order to return NULL if the above conditions are met. 2. Calls to lookupKeyRead() in commands actually writing to the data set are repliaced with calls to lookupKeyWrite(). There are redundand checks, so for example, if in "2" something was overlooked, we should be still safe, since anyway, when the master writes the behavior is to don't care about what expireIfneeded() returns. This commit is related to #1768, #1770, #2131.
-
- 02 Dec, 2014 1 commit
-
-
antirez authored
Ref: issue #2175
-
- 09 Sep, 2014 1 commit
-
-
xiaost authored
*SCAN will cause redis server to hang for seconds after millions of keys was deleted by SCAN/DEL pairs
-
- 13 Aug, 2014 1 commit
-
-
antirez authored
-
- 08 Aug, 2014 1 commit
-
-
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
-
- 07 Aug, 2014 1 commit
-
-
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
-
- 26 Jun, 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
-
- 14 May, 2014 1 commit
-
-
antirez authored
The previous code handling a lost slot (by another master with an higher configuration for the slot) was defensive, considering it an error and putting the cluster in an odd state requiring redis-cli fix. This was changed, because actually this only happens either in a legitimate way, with failovers, or when the admin messed with the config in order to reconfigure the cluster. So the new code instead will try to make sure that the keys stored match the new slots map, by removing all the keys in the slots we lost ownership from. The function that deletes the keys from the lost slots is called only if the node does not lose all its slots (resulting in a reconfiguration as a slave of the node that got ownership). This is an optimization since the replication code will anyway flush all the instance data in a faster way.
-
- 17 Apr, 2014 1 commit
-
-
antirez authored
-
- 10 Apr, 2014 1 commit
-
-
Matt Stancliff authored
Deleting an expired key should return 0, not success. Fixes #1648
-
- 30 Mar, 2014 1 commit
-
-
antirez authored
All the Redis functions that need to modify the string value of a key in a destructive way (APPEND, SETBIT, SETRANGE, ...) require to make the object unshared (if refcount > 1) and encoded in raw format (if encoding is not already REDIS_ENCODING_RAW). This was cut & pasted many times in multiple places of the code. This commit puts the small logic needed into a function called dbUnshareStringValue().
-
- 20 Mar, 2014 2 commits
-
-
antirez authored
-
antirez authored
For testing purposes it is handy to have a very high resolution of the LRU clock, so that it is possible to experiment with scripts running in just a few seconds how the eviction algorithms works. This commit allows Redis to use the cached LRU clock, or a value computed on demand, depending on the resolution. So normally we have the good performance of a precomputed value, and a clock that wraps in many days using the normal resolution, but if needed, changing a define will switch behavior to an high resolution LRU clock.
-
- 10 Mar, 2014 3 commits