- 07 Feb, 2014 1 commit
-
-
antirez authored
-
- 03 Feb, 2014 1 commit
-
-
antirez authored
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.
-
- 10 Dec, 2013 1 commit
-
-
antirez authored
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).
-
- 05 Dec, 2013 1 commit
-
-
antirez authored
-
- 05 Nov, 2013 6 commits
-
-
antirez authored
Thanks to @badboy for reporting it.
-
antirez authored
The previous implementation of SCAN parsed the cursor in the generic function implementing SCAN, SSCAN, HSCAN and ZSCAN. The actual higher-level command implementation only checked for empty keys and return ASAP in that case. The result was that inverting the arguments of, for instance, SSCAN for example and write: SSCAN 0 key Instead of SSCAN key 0 Resulted into no error, since 0 is a non-existing key name very likely. Just the iterator returned no elements at all. In order to fix this issue the code was refactored to extract the function to parse the cursor and return the error. Every higher level command implementation now parses the cursor and later checks if the key exist or not. -
antirez authored
The previous implementation assumed that the first call always happens with cursor set to 0, this may not be the case, and we want to return 0 anyway otherwise the (broken) client code will loop forever.
-
antirez authored
-
antirez authored
This fixes issue #1360 and #1362.
-
antirez authored
-
- 31 Oct, 2013 3 commits
- 29 Oct, 2013 13 commits
-
-
antirez authored
-
antirez authored
The new implementation is capable of iterating the keyspace but also sets, hashes, and sorted sets, and can be used to implement SSCAN, ZSCAN and HSCAN.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
Pieter Noordhuis authored
-
Pieter Noordhuis authored
-
- 27 Jun, 2013 1 commit
-
-
antirez authored
-
- 28 Mar, 2013 1 commit
-
-
antirez authored
-
- 26 Mar, 2013 1 commit
-
-
antirez authored
This commit fixes two corner cases for the TTL command. 1) When the key was already logically expired (expire time older than current time) the command returned -1 instead of -2. 2) When the key was existing and the expire was found to be exactly 0 (the key was just about to expire), the command reported -1 (that is, no expire) instead of a TTL of zero (that is, about to expire).
-
- 12 Feb, 2013 1 commit
-
-
antirez authored
-
- 28 Jan, 2013 5 commits
-
-
antirez authored
-
antirez authored
When keyspace events are enabled, the overhead is not sever but noticeable, so this commit introduces the ability to select subclasses of events in order to avoid to generate events the user is not interested in. The events can be selected using redis.conf or CONFIG SET / GET.
-
antirez authored
-
antirez authored
-
antirez authored
-
- 19 Jan, 2013 2 commits
-
-
antirez authored
This commit fixes issue #875 that was caused by the following events: 1) There is an active child doing BGSAVE. 2) flushall is called (or any other condition that makes Redis killing the saving child process). 3) An error is sensed by Redis as the child exited with an error (killed by a singal), that stops accepting write commands until a BGSAVE happens to be executed with success. Whitelisting SIGUSR1 and making sure Redis always uses this signal in order to kill its own children fixes the issue.
-
guiquanz authored
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
-
- 12 Nov, 2012 1 commit
-
-
antirez authored
The previous behavior was to return -1 if: 1) Existing key but without an expire set. 2) Non existing key. Now the second case is handled in a different, and TTL will return -2 if the key does not exist at all. PTTL follows the same behavior as well.
-
- 08 Nov, 2012 1 commit
-
-
antirez authored
-
- 11 Sep, 2012 1 commit
-
-
antirez authored
Unfortunately we had still the lame atoi() without any error checking in place, so "SELECT foo" would work as "SELECT 0". This was not an huge problem per se but some people expected that DB can be strings and not just numbers, and without errors you get the feeling that they can be numbers, but not the behavior. Now getLongFromObjectOrReply() is used as almost everybody else across the code, generating an error if the number is not an integer or overflows the long type. Thanks to @mipearson for reporting that on Twitter.
-