- 09 Jul, 2018 1 commit
-
-
WuYunlong authored
-
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 29 Jun, 2018 1 commit
-
-
antirez authored
Making it more similar to KILL.
-
- 28 Jun, 2018 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 27 Jun, 2018 6 commits
- 13 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 07 Jun, 2018 1 commit
-
-
Itamar Haber authored
-
- 22 Mar, 2018 2 commits
- 15 Mar, 2018 2 commits
- 28 Feb, 2018 1 commit
-
-
antirez authored
Many thanks to @Plasma that spotted this problem reviewing the code.
-
- 27 Feb, 2018 1 commit
-
-
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.
-
- 13 Feb, 2018 1 commit
-
-
antirez authored
See #3832.
-
- 18 Jan, 2018 1 commit
-
-
Guy Benoish authored
When feeding the master with a high rate traffic the the slave's feed is much slower. This causes the replication buffer to grow (indefinitely) which leads to slave disconnection. The problem is that writeToClient() decides to stop writing after NET_MAX_WRITES_PER_EVENT writes (In order to be fair to clients). We should ignore this when the client is a slave. It's better if clients wait longer, the alternative is that the slave has no chance to stay in sync in this situation.
-
- 11 Jan, 2018 1 commit
-
-
antirez authored
Related to #4568.
-
- 29 Dec, 2017 2 commits
-
-
Oran Agra authored
-
Oran Agra authored
- protocol parsing (processMultibulkBuffer) was limitted to 32big positions in the buffer readQueryFromClient potential overflow - rioWriteBulkCount used int, although rioWriteBulkString gave it size_t - several places in sds.c that used int for string length or index. - bugfix in RM_SaveAuxField (return was 1 or -1 and not length) - RM_SaveStringBuffer was limitted to 32bit length
-
- 06 Dec, 2017 1 commit
-
-
antirez authored
The main change introduced by this commit is pretending that help arrays are more text than code, thus indenting them at level 0. This improves readability, and is an old practice when defining arrays of C strings describing text. Additionally a few useless return statements are removed, and the HELP subcommand capitalized when printed to the user.
-
- 05 Dec, 2017 3 commits
-
-
Itamar Haber authored
-
Itamar Haber authored
-
antirez authored
We have this operation in two places: when caching the master and when linking a new client after the client creation. By having an API for this we avoid incurring in errors when modifying one of the two places forgetting the other. The function is also a good place where to document why we cache the linked list node. Related to #4497 and #4210.
-
- 03 Dec, 2017 1 commit
-
-
Itamar Haber authored
-
- 01 Dec, 2017 2 commits
- 30 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
-
- 28 Nov, 2017 1 commit
-
-
Itamar Haber authored
This adds a new `addReplyHelp` helper that's used by commands when returning a help text. The following commands have been touched: DEBUG, OBJECT, COMMAND, PUBSUB, SCRIPT and SLOWLOG. WIP Fix entry command table entry for OBJECT for HELP option. After #4472 the command may have just 2 arguments. Improve OBJECT HELP descriptions. See #4472. WIP 2 WIP 3
-
- 11 Jul, 2017 1 commit
-
-
antirez authored
See issue #3844 for more information.
-
- 05 Jul, 2017 1 commit
-
-
spinlock authored
-
- 04 Jul, 2017 1 commit
-
-
antirez authored
Redis clients need to have an instantaneous idea of the amount of memory they are consuming (if the number is not exact should at least be proportional to the actual memory usage). We do that adding and subtracting the SDS length when pushing / popping from the client->reply list. However it is quite simple to add bugs in such a setup, by not taking the objects in the list and the count in sync. For such reason, Redis has an assertion to track counts near 2^64: those are always the result of the counter wrapping around because we subtract more than we add. This commit adds the symmetrical assertion: when the list is empty since we sent everything, the reply_bytes count should be zero. Thanks to the new assertion it should be simple to also detect the other problem, where the count slowly increases because of over-counting. The assertion adds a conditional in the code that sends the buffer to the socket but should not create any measurable performance slowdown, listLength() just accesses a structure field, and this code path is totally dominated by write(2). Related to #4100.
-
- 09 May, 2017 1 commit
-
-
antirez authored
More work to do with server.unixtime and similar. Need to write Helgrind suppression file in order to suppress the valse positives.
-
- 19 Apr, 2017 1 commit
-
-
antirez authored
This bug was discovered by @kevinmcgehee and constituted a major hidden bug in the PSYNC2 implementation, caused by the propagation from the master of incomplete commands to slaves. The bug had several results: 1. Borrowing from Kevin text in the issue: "Given that slaves blindly copy over their master's input into their own replication backlog over successive read syscalls, it's possible that with large commands or small TCP buffers, partial commands are present in this buffer. If the master were to fail before successfully propagating the entire command to a slave, the slaves will never execute the partial command (since the client is invalidated) but will copy it to replication backlog which may relay those invalid bytes to its slaves on PSYNC2, corrupting the backlog and possibly other valid commands that follow the failover. Simple command boundaries aren't sufficient to capture this, either, because in the case of a MULTI/EXEC block, if the master successfully propagates a subset of the commands but not the EXEC, then the transaction in the backlog becomes corrupt and could corrupt other slaves that consume this data." 2. As identified by @yangsiran later, there is another effect of the bug. For the same mechanism of the first problem, a slave having another slave, could receive a full resynchronization request with an already half-applied command in the backlog. Once the RDB is ready, it will be sent to the slave, and the replication will continue sending to the sub-slave the other half of the command, which is not valid. The fix, designed by @yangsiran and @antirez, and implemented by @antirez, uses a secondary buffer in order to feed the sub-masters and update the replication backlog and offsets, only when a given part of the query buffer is actually *applied* to the state of the instance, that is, when the command gets processed and the command is not pending in the Redis transaction buffer because of CLIENT_MULTI state. Given that now the backlog and offsets representation are in agreement with the actual processed commands, both issue 1 and 2 should no longer be possible. Thanks to @kevinmcgehee, @yangsiran and @oranagra for their work in identifying and designing a fix for this problem.
-
- 12 Apr, 2017 1 commit
-
-
antirez authored
-
- 23 Feb, 2017 1 commit
-
-
oranagra authored
since slave isn't replying to it's master, these errors go unnoticed. since we don't expect the master to send garbadge to the slave, this should be safe. (as long as we don't log OOM errors there)
-