- 18 Mar, 2019 4 commits
-
-
antirez authored
-
antirez authored
-
John Sully authored
-
antirez authored
Bug signaled by @vattezhang in PR #5940 but fixed differently.
-
- 14 Mar, 2019 2 commits
-
-
Guy Benoish authored
-
Guy Benoish authored
-
- 10 Mar, 2019 2 commits
-
-
antirez authored
-
John Sully authored
-
- 20 Feb, 2019 1 commit
-
-
antirez authored
-
- 31 Jan, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 21 Dec, 2018 1 commit
-
-
Chris Lamb authored
If we encounter an unsupported protocol in the "bind" list, don't ipso-facto consider it a fatal error. We continue to abort startup if there are no listening sockets at all. This ensures that the lack of IPv6 support does not prevent Redis from starting on Debian where we try to bind to the ::1 interface by default (via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some container systems) would simply fail to start Redis after the initiall call to apt(8). This is similar to the case for where "bind" is not specified: https://github.com/antirez/redis/issues/3894 ... and was based on the corresponding PR: https://github.com/antirez/redis/pull/4108 ... but also adds EADDRNOTAVAIL to the list of errors to catch which I believe is missing from there. This issue was raised in Debian as both <https://bugs.debian.org/900284> & <https://bugs.debian.org/914354>.
-
- 11 Dec, 2018 4 commits
-
-
antirez authored
-
antirez authored
Fake clients are used in special situations and are not linked to the normal clients list, freeing them will always result in Redis crashing in one way or the other. It's not common to send replies to fake clients, but we have one usage in the modules API. When a client is blocked, we associate to the blocked client object (that is safe to manipulate in a thread), a fake client that accumulates replies. So because of this bug there was the problem described in issue #5443. The fix was verified to work with the provided example module. To write a regression is very hard and unlikely to be triggered in the future.
-
Guy Benoish authored
-
antirez authored
See #5632.
-
- 14 Nov, 2018 2 commits
-
-
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.
-
zhaozhao.zz authored
-
- 31 Oct, 2018 3 commits
-
-
antirez authored
This logs what happens in the context of the fix in PR #5367.
-
Andrey Bugaevskiy authored
-
Andrey Bugaevskiy authored
During the full database resync we may still have unsaved changes on the receiving side. This causes a race condition between synced data rename/load and the rename of rdbSave tempfile.
-
- 10 Oct, 2018 3 commits
-
-
antirez authored
Related to #5201. I removed the !!! Warning part since compared to the other errors, a missing EXEC is in theory a normal happening in the AOF file, at least in theory: may happen in a differnet number of situations, and it's probably better to don't give the user the feeling that something really bad happened.
-
zhaozhao.zz authored
-
antirez authored
Realted to #5201.
-
- 03 Aug, 2018 3 commits
-
-
antirez authored
-
antirez authored
PR #5081 fixes an "interesting" bug about Redis Cluster failover but in general about the updating of repl_down_since, that is used in order to count the time a slave was left disconnected from its master. While the fix provided resolves the specific issue, in general the validity of repl_down_since is limited to states that are different than the state CONNECTED, and the disconnected time is set when the state is DISCONNECTED. However from CONNECTED to other states, the state machine must always go to DISCONNECTED first. So it makes sense to set the field to zero (since it is meaningless in that context) when the state is set to CONNECTED.
-
WuYunlong authored
automatically as expected.
-
- 23 Jul, 2018 1 commit
-
-
Oran Agra authored
The slave sends \n keepalive messages to the master while parsing the rdb, and later sends REPLCONF ACK once a second. rarely, the master recives both a linefeed char and a REPLCONF in the same read, \n*3\r\n$8\r\nREPLCONF\r\n... and it tries to trim two chars (\r\n) from the query buffer, trimming the '*' from *3\r\n$8\r\nREPLCONF\r\n... then the master tries to process a command starting with '3' and replies to the slave a bunch of -ERR and one +OK. although the slave silently ignores these (prints a log message), this corrupts the replication offset at the slave since the slave increases the replication offset, and the master did not. other than the fix in processInlineBuffer, i did several other improvments while hunting this very rare bug. - when redis replies with "unknown command" it includes a portion of the arguments, not just the command name. so it would be easier to understand what was recived, in my case, on the slave side, it was -ERR, but the "arguments" were the interesting part (containing info on the error). - about a year ago i added code in addReplyErrorLength to print the error to the log in case of a reply to master (since this string isn't actually trasmitted to the master), now changed that block to print a similar log message to indicate an error being sent from the master to the slave. note that the slave is marked as CLIENT_SLAVE only after PSYNC was received, so this will not cause any harm for REPLCONF, and will only indicate problems that are gonna corrupt the replication stream anyway. - two places were c->reply was emptied, and i wanted to reset sentlen this is a precaution (i did not actually see such a problem), since a non-zero sentlen will cause corruption to be transmitted on the socket.
-
- 29 Jun, 2018 3 commits
-
-
zhaozhao.zz authored
-
antirez authored
Thanks to @kevinmcgehee for signaling the issue and reasoning about the consequences and potential fixes. Issue #5015.
-
antirez authored
The ability of "SENTINEL SET" to change the reconfiguration script at runtime is a problem even in the security model of Redis: any client inside the network may set any executable to be ran once a failover is triggered. This option adds protection for this problem: by default the two SENTINEL SET subcommands modifying scripts paths are denied. However the user is still able to rever that using the Sentinel configuration file in order to allow such a feature.
-
- 13 Jun, 2018 2 commits
- 01 Jun, 2018 1 commit
-
-
赵磊 authored
-
- 29 May, 2018 7 commits
-
-
dejun.xdj authored
-
dejun.xdj authored
In case that the incoming repeat parameter is negative and causes a deadless loop.
-
dejun.xdj authored
To be in consistent with the original definition.
-
dejun.xdj authored
If command like "-1 set a b" is sent with redis-cli, it will cause a deadless loop. So some repeat value checking logic is added to avoid this.
-
dejun.xdj authored
Put the repeat option checking code a little forward to avoid repeat logic.
-
dejun.xdj authored
-
dejun.xdj authored
-