- 30 Jul, 2018 3 commits
- 25 Jul, 2018 3 commits
-
-
antirez authored
Related to #4852.
-
antirez authored
-
zhaozhao.zz authored
-
- 24 Jul, 2018 6 commits
- 23 Jul, 2018 5 commits
-
-
antirez authored
Related to #5157. The PR author correctly indentified that the check was duplicated, but removing the second one introduces a bug that was fixed in the past (hence the duplication). Instead we can remove the first instance of the check without issues.
-
antirez authored
-
antirez authored
Related to #4883.
-
antirez authored
-
antirez authored
This way we can remember what the user configured HZ is, but change the actual HZ dynamically if needed in the dynamic HZ feature implementation.
-
- 22 Jul, 2018 3 commits
-
-
Itamar Haber authored
-
zhaozhao.zz authored
-
Oran Agra authored
-
- 21 Jul, 2018 2 commits
-
-
dsomeshwar authored
-
WuYunlong authored
-
- 20 Jul, 2018 2 commits
- 19 Jul, 2018 8 commits
- 18 Jul, 2018 3 commits
-
-
antirez authored
See #5135 for more context.
-
antirez authored
See #5135 for some context.
-
Oran Agra authored
on slower machines, the active defrag test tended to fail. although the fragmentation ratio was below the treshold, the defragger was still in the middle of a scan cycle. this commit changes: - the defragger uses the current fragmentation state, rather than the cache one that is updated by server cron every 100ms. this actually fixes a bug of starting one excess scan cycle - the test lets the defragger use more CPU cycles, in hope that the defrag will be faster, but also give it more time before we give up.
-
- 17 Jul, 2018 5 commits
-
-
antirez authored
-
antirez authored
Related to #5135, see discussion there.
-
dejun.xdj authored
It's already checked if xreadgroup is set and groupname is NULL.
-
dejun.xdj authored
Redis will always return an empty result when '$' ID is specified with xreadgroup command, it's meaningless.
-
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.
-