- 08 Jun, 2018 1 commit
-
-
赵磊 authored
-
- 28 Feb, 2018 1 commit
-
-
antirez authored
Many thanks to @Plasma that spotted this problem reviewing the code.
-
- 27 Feb, 2018 4 commits
-
-
antirez authored
AE_BARRIER was implemented like: - Fire the readable event. - Do not fire the writabel event if the readable fired. However this may lead to the writable event to never be called if the readable event is always fired. There is an alterantive, we can just invert the sequence of the calls in case AE_BARRIER is set. This commit does that.
-
antirez authored
In case the write handler is already installed, it could happen that we serve the reply of a query in the same event loop cycle we received it, preventing beforeSleep() from guaranteeing that we do the AOF fsync before sending the reply to the client. The AE_BARRIER mechanism, introduced in a previous commit, prevents this problem. This commit makes actual use of this new feature to fix the bug.
-
antirez authored
Add AE_BARRIER to the writable event loop so that slaves requesting votes can't be served before we re-enter the event loop in the next iteration, so clusterBeforeSleep() will fsync to disk in time. Also add the call to explicitly fsync, given that we modified the last vote epoch variable.
-
antirez authored
AOF fsync=always, and certain Redis Cluster bus operations, require to fsync data on disk before replying with an acknowledge. In such case, in order to implement Group Commits, we want to be sure that queries that are read in a given cycle of the event loop, are never served to clients in the same event loop iteration. This way, by using the event loop "before sleep" callback, we can fsync the information just one time before returning into the event loop for the next cycle. This is much more efficient compared to calling fsync() multiple times. Unfortunately because of a bug, this was not always guaranteed: the actual way the events are installed was the sole thing that could control. Normally this problem is hard to trigger when AOF is enabled with fsync=always, because we try to flush the output buffers to the socekt directly in the beforeSleep() function of Redis. However if the output buffers are full, we actually install a write event, and in such a case, this bug could happen. This change to ae.c modifies the event loop implementation to make this concept explicit. Write events that are registered with: AE_WRITABLE|AE_BARRIER Are guaranteed to never fire after the readable event was fired for the same file descriptor. In this way we are sure that data is persisted to disk before the client performing the operation receives an acknowledged. However note that this semantics does not provide all the guarantees that one may believe are automatically provided. Take the example of the blocking list operations in Redis. With AOF and fsync=always we could have: Client A doing: BLPOP myqueue 0 Client B doing: RPUSH myqueue a b c In this scenario, Client A will get the "a" elements immediately after the Client B RPUSH will be executed, even before the operation is persisted. However when Client B will get the acknowledge, it can be sure that "b,c" are already safe on disk inside the list. What to note here is that it cannot be assumed that Client A receiving the element is a guaranteed that the operation succeeded from the point of view of Client B. This is due to the fact that the barrier exists within the same socket, and not between different sockets. However in the case above, the element "a" was not going to be persisted regardless, so it is a pretty synthetic argument.
-
- 21 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
-
- 08 Nov, 2017 1 commit
-
-
kmiku7 authored
-
- 06 Nov, 2017 1 commit
-
-
antirez authored
Normally in modern Redis you can't create zero-len lists, however it's possible to load them from old RDB files generated, for instance, using Redis 2.8 (see issue #4409). The "Right Thing" would be not loading such lists at all, but this requires to hook in rdb.c random places in a not great way, for a problem that is at this point, at best, minor. Here in this commit instead I just fix the fact that zero length lists, materialized as quicklists with the first node set to NULL, were iterated in the wrong way while they are saved, leading to a crash. The other parts of the list implementation are apparently able to deal with empty lists correctly, even if they are no longer a thing.
-
- 31 Oct, 2017 1 commit
-
-
antirez authored
There was not enough sanity checking in the code loading the slots of Redis Cluster from the nodes.conf file, this resulted into the attacker's ability to write data at random addresses in the process memory, by manipulating the index of the array. The bug seems exploitable using the following techique: the config file may be altered so that one of the nodes gets, as node ID (which is the first field inside the structure) some data that is actually executable: then by writing this address in selected places, this node ID part can be executed after a jump. So it is mostly just a matter of effort in order to exploit the bug. In practice however the issue is not very critical because the bug requires an unprivileged user to be able to modify the Redis cluster nodes configuration, and at the same time this should result in some gain. However Redis normally is unprivileged as well. Yet much better to have this fixed indeed. Fix #4278.
-
- 21 Sep, 2017 1 commit
-
-
antirez authored
-
- 18 Sep, 2017 1 commit
-
-
Oran Agra authored
when SHUTDOWN command is recived it is possible that some of the recent command were not yet flushed from the AOF buffer, and the server experiences data loss at shutdown.
-
- 28 Jul, 2017 1 commit
-
-
antirez authored
-
- 24 Jul, 2017 8 commits
-
-
Jan-Erik Rediger authored
Fixes #2258
-
WuYunlong authored
-
Byron Grobe authored
-
Jan-Erik Rediger authored
It's not POSIX (BSD systems have -E instead) and we don't actually need it. Closes #1922
-
Leon Chen authored
-
Leon Chen authored
-
liangsijian authored
-
antirez authored
This function failed when an internal-only flag was set as an only flag in a node: the string was trimmed expecting a final comma before exiting the function, causing a crash. See issue #4142. Moreover generation of flags representation only needed at DEBUG log level was always performed: a waste of CPU time. This is fixed as well by this commit.
-
- 11 Jul, 2017 1 commit
-
-
antirez authored
Close #3766.
-
- 30 Jun, 2017 2 commits
-
-
antirez authored
-
antirez authored
Issue #4084 shows how for a design error, GEORADIUS is a write command because of the STORE option. Because of this it does not work on readonly slaves, gets redirected to masters in Redis Cluster even when the connection is in READONLY mode and so forth. To break backward compatibility at this stage, with Redis 4.0 to be in advanced RC state, is problematic for the user base. The API can be fixed into the unstable branch soon if we'll decide to do so in order to be more consistent, and reease Redis 5.0 with this incompatibility in the future. This is still unclear. However, the ability to scale GEO queries in slaves easily is too important so this commit adds two read-only variants to the GEORADIUS and GEORADIUSBYMEMBER command: GEORADIUS_RO and GEORADIUSBYMEMBER_RO. The commands are exactly as the original commands, but they do not accept the STORE and STOREDIST options.
-
- 27 Jun, 2017 6 commits
-
-
Suraj Narkhede authored
1. brpop last key index, thus checking all keys for slots. 2. Memory leak in clusterRedirectBlockedClientIfNeeded. 3. Remove while loop in clusterRedirectBlockedClientIfNeeded.
-
Suraj Narkhede authored
-
antirez authored
-
Antonio Mallia authored
-
Zachary Marquez authored
Proposed fix to https://github.com/antirez/redis/issues/4027
-
antirez authored
-
- 22 Jun, 2017 4 commits
- 20 Jun, 2017 4 commits
-
-
minghang.zmh authored
-
xuchengxuan authored
-
cbgbt authored
-
Aric Huang authored
Fix a few typos/adjust wording in `create-cluster` README
-
- 14 Jun, 2017 1 commit
-
-
Salvatore Sanfilippo authored
Implement getKeys procedure for georadius and georadiusbymember commands
-
- 17 May, 2017 1 commit
-
-
antirez authored
-