- 06 Jun, 2018 2 commits
-
-
shenlongxing authored
-
antirez authored
Close #4989.
-
- 05 Jun, 2018 2 commits
- 04 Jun, 2018 3 commits
-
-
antirez authored
Now that we have SETID, the inetrnals of consumer groups should be able to handle the case of the same message delivered multiple times just as a side effect of calling XREADGROUP. Normally this should never happen but if the admin manually "XGROUP SETID mykey mygroup 0", messages will get re-delivered to clients waiting for the ">" special ID. The consumer groups internals were not able to handle the case of a message re-delivered in this circumstances that was already assigned to another owner.
-
antirez authored
-
antirez authored
-
- 03 Jun, 2018 1 commit
-
-
Yossi Gottlieb authored
-
- 01 Jun, 2018 1 commit
-
-
artix authored
-
- 31 May, 2018 3 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
artix authored
-
- 30 May, 2018 1 commit
-
-
Remi Collet authored
-
- 29 May, 2018 2 commits
-
-
antirez authored
The AOF tail of a combined RDB+AOF is based on the premise of applying the AOF commands to the exact state that there was in the server while the RDB was persisted. By expiring keys while loading the RDB file, we change the state, so applying the AOF tail later may change the state. Test case: * Time1: SET a 10 * Time2: EXPIREAT a $time5 * Time3: INCR a * Time4: PERSIT A. Start bgrewiteaof with RDB preamble. The value of a is 11 without expire time. * Time5: Restart redis from the RDB+AOF: consistency violation. Thanks to @soloestoy for providing the patch. Thanks to @trevor211 for the original issue report and the initial fix. Check issue #4950 for more info.
-
WuYunlong authored
we add a new slave, and do a failover, eighter by manual or not, other local slaves will delete the expired keys properly.
-
- 27 May, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 25 May, 2018 8 commits
-
-
antirez authored
-
zhaozhao.zz authored
-
antirez authored
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
-
antirez authored
-
Mota authored
-
- 24 May, 2018 1 commit
-
-
antirez authored
They failed when active defrag could not be activated because the Jemalloc version does not include the additional APIs.
-
- 23 May, 2018 1 commit
-
-
antirez authored
See issue #2819 for details. The gist is that when we want to send INFO because we are over the time, we used to send only INFO commands, no longer sending PING commands. However if a master fails exactly when we are about to send an INFO command, the PING times will result zero because the PONG reply was already received, and we'll fail to send more PINGs, since we try only to send INFO commands: the failure detector will delay until the connection is closed and re-opened for "long timeout". This commit changes the logic so that we can send the three kind of messages regardless of the fact we sent another one already in the same code path. It could happen that we go over the message limit for the link by a few messages, but this is not significant. However now we'll not introduce delays in sending commands just because there was something else to send at the same time.
-
- 22 May, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 21 May, 2018 3 commits
- 19 May, 2018 1 commit
-
-
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.
-
- 18 May, 2018 2 commits
- 17 May, 2018 1 commit
-
-
Oran Agra authored
problems fixed: * failing to read fragmentation information from jemalloc * overflow in jemalloc fragmentation hint to the defragger * test suite not triggering eviction after population
-
- 16 May, 2018 4 commits
- 15 May, 2018 2 commits