- 01 10月, 2015 3 次提交
- 14 9月, 2015 2 次提交
-
-
由 antirez 提交于
getExpire() returns -1 when no expire exists. Related to #2765.
-
由 antirez 提交于
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 7月, 2015 2 次提交
- 26 7月, 2015 4 次提交
- 14 7月, 2015 1 次提交
-
-
由 antirez 提交于
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 2月, 2015 1 次提交
-
-
由 antirez 提交于
Fixes issue #2392.
-
- 12 12月, 2014 1 次提交
-
-
由 clark.kang 提交于
-
- 10 12月, 2014 1 次提交
-
-
由 antirez 提交于
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.
-
- 03 12月, 2014 1 次提交
-
-
由 antirez 提交于
Ref: issue #2175
-
- 09 9月, 2014 1 次提交
-
-
由 xiaost 提交于
*SCAN will cause redis server to hang for seconds after millions of keys was deleted by SCAN/DEL pairs
-
- 13 8月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 08 8月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
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 8月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
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
-
- 27 6月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 21 5月, 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
-
- 14 5月, 2014 1 次提交
-
-
由 antirez 提交于
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 4月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 11 4月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
Deleting an expired key should return 0, not success. Fixes #1648
-
- 31 3月, 2014 1 次提交
-
-
由 antirez 提交于
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 3月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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 3月, 2014 8 次提交
-
-
由 antirez 提交于
It does not make sense to pass multiple store options, so, better to handle it ;-)
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Previously we used zunionInterGetKeys(), however after this function was fixed to account for the destination key (not needed when the API was designed for "diskstore") the two set of commands can no longer be served by an unique keys-extraction function.
-
由 antirez 提交于
-
由 antirez 提交于
This API originated from the "diskstore" experiment, not for Redis Cluster itself, so there were legacy/useless things trying to differentiate between keys that are going to be overwritten and keys that need to be fetched from disk (preloaded). All useless with Cluster, so removed with the result of code simplification.
-
由 antirez 提交于
Everything was pretty clear again from the initial statements.
-
- 08 3月, 2014 1 次提交
-
-
由 Matt Stancliff 提交于
The previous implementation wasn't taking into account the storage key in position 1 being a requirement (it was only counting the source keys in positions 3 to N). Fixes antirez/redis#1581
-
- 07 2月, 2014 1 次提交
-
-
由 antirez 提交于
-
- 03 2月, 2014 1 次提交
-
-
由 antirez 提交于
Keys expiring in the middle of the execution of Lua scripts are to create inconsistencies in masters and / or AOF files. See the following example: if redis.call("exists",KEYS[1]) == 1 then redis.call("incr","mycounter") end if redis.call("exists",KEYS[1]) == 1 then return redis.call("incr","mycounter") end The script executes two times the same *if key exists then incrementcounter* logic. However the two executions will work differently in the master and the slaves, provided some unlucky timing happens. In the master the first time the key may still exist, while the second time the key may no longer exist. This will result in the key incremented just one time. However as a side effect the master will generate a synthetic `DEL` command in the replication channel in order to force the slaves to expire the key (given that key expiration is master-driven). When the same script will run in the slave, the key will no longer be there, so the script will not increment the key. The key idea used to implement the expire-at-first-lookup semantics was provided by Marc Gravell.
-
- 11 12月, 2013 1 次提交
-
-
由 antirez 提交于
Redis hash table implementation has many non-blocking features like incremental rehashing, however while deleting a large hash table there was no way to have a callback called to do some incremental work. This commit adds this support, as an optiona callback argument to dictEmpty() that is currently called at a fixed interval (one time every 65k deletions).
-