- 15 Oct, 2018 1 commit
-
-
antirez authored
Issue #5433.
-
- 09 Oct, 2018 6 commits
-
-
antirez authored
See #5141.
-
zhaozhao.zz authored
Slaves and rebooting redis may have different radix tree struct, by different stream* config options. So propagating approximated MAXLEN to AOF/slaves may lead to date inconsistency.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
If we rewrite the MAXLEN argument as zero when no trimming was performed, date between master and slave and aof will be inconsistent, because `xtrim maxlen 0` means delete all entries in stream.
-
antirez authored
-
- 03 Oct, 2018 5 commits
-
-
antirez authored
-
antirez authored
Most of the times the pointer will remain the same since integers of similar size don't take more space in listpacks. Related to #5210.
-
zhaozhao.zz authored
-
antirez authored
-
Guy Korland authored
-
- 29 Aug, 2018 3 commits
-
-
Sascha Roland authored
The conclusion, that a xread request can be answered syncronously in case that the stream's last_id is larger than the passed last-received-id parameter, assumes, that there must be entries present, which could be returned immediately. This assumption fails for empty streams that actually contained some entries which got removed by xdel, ... . As result, the client is answered synchronously with an empty result, instead of blocking for new entries to arrive. An additional check for a non-empty stream is required.
-
dejun.xdj authored
-
shenlongxing authored
-
- 02 Aug, 2018 3 commits
- 30 Jul, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 24 Jul, 2018 2 commits
-
-
antirez authored
After #5161 the code could be made a bit more obvious for newcomers.
-
zhaozhao.zz authored
-
- 23 Jul, 2018 1 commit
-
-
antirez authored
For some reason I made a merge fiasco between 5.0 and unstable. This fixes the error introduced by merging unstable.
-
- 17 Jul, 2018 3 commits
- 16 Jul, 2018 5 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
antirez authored
Related to #5129.
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 14 Jul, 2018 1 commit
-
-
dejun.xdj authored
-
- 12 Jul, 2018 2 commits
-
-
antirez authored
We don't want to increment the deliveries here, because the sysadmin reset the consumer group so the desire is likely to restart processing, and having the PEL polluted with old information is not useful but probably confusing. Related to #5111.
-
antirez authored
We don't really need to distinguish between the case the consumer is the same or is a different one.
-
- 10 Jul, 2018 3 commits
-
-
antirez authored
-
antirez authored
To simplify the semantics of blocking for a group, this commit changes the implementation to better match the description we provide of conusmer groups: blocking for > will make the consumer waiting for new elements in the group. However blocking for any other ID will always serve the local history of the consumer. However it must be noted that the > ID is actually an alias for the special ID ms/seq of UINT64_MAX,UINT64_MAX.
-
dejun.xdj authored
For issue #5111.
-
- 09 Jul, 2018 1 commit
-
-
dejun.xdj authored
Save NOACK option into client.blockingState structure.
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 02 Jul, 2018 1 commit
-
-
antirez authored
-
- 27 Jun, 2018 1 commit
-
-
Mustafa Paltun authored
-