- 12 Jun, 2018 23 commits
-
-
antirez authored
We unblocked the client too early, when the group name object was no longer valid in client->bpop, so propagating XCLAIM later in streamPropagateXCLAIM() deferenced a field already set to NULL.
-
antirez authored
Removing the fix about 50% of the times the test will not be able to pass cleanly. It's very hard to write a test that will always fail, or actually, it is possible but then it's likely that it will consistently pass if we change some random bit, so better to use randomization here.
-
antirez authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
michael-grunder authored
-
shenlongxing authored
-
antirez authored
-
antirez authored
-
antirez authored
-
shenlongxing authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Also add the concept of size/items limit, instead of just having as limit the number of bytes.
-
shenlongxing authored
-
michael-grunder authored
-
Krzysztof Filipek authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 06 Jun, 2018 1 commit
-
-
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.
-
Yossi Gottlieb authored
-
antirez authored
-
- 01 Jun, 2018 5 commits
-
-
赵磊 authored
-
artix authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
Mota authored
-
- 31 May, 2018 3 commits
-
-
antirez authored
-
Remi Collet authored
-
artix authored
-
- 29 May, 2018 3 commits
-
-
antirez authored
-
antirez authored
-
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.
-