- 28 4月, 2020 2 次提交
-
-
由 Guy Benoish 提交于
-
由 Guy Benoish 提交于
Introducing XINFO STREAM <key> FULL
-
- 24 4月, 2020 1 次提交
-
-
由 antirez 提交于
-
- 23 4月, 2020 1 次提交
-
-
由 antirez 提交于
-
- 22 4月, 2020 1 次提交
-
-
由 Valentino Geron 提交于
-
- 21 4月, 2020 1 次提交
-
-
由 antirez 提交于
-
- 17 4月, 2020 1 次提交
-
-
由 antirez 提交于
See issue #7105.
-
- 10 4月, 2020 1 次提交
-
-
由 antirez 提交于
Streams items are similar to dictionaries, however they preserve both the order, and allow for duplicated field names. So a map is not a semantically sounding way to deal with this. https://twitter.com/antirez/status/1248261087553880069
-
- 30 3月, 2020 1 次提交
-
-
由 Guy Benoish 提交于
propagate_last_id is declared outside of the loop but used only from within the loop. Once it's '1' it will never go back to '0' and will replicate XSETID even for IDs that don't actually change the last_id. While not a serious bug (XSETID always used group->last_id so there's no risk), it does causes redundant traffic between master and its replicas
-
- 26 3月, 2020 2 次提交
-
-
由 Valentino Geron 提交于
-
由 Valentino Geron 提交于
First, we must parse the IDs, so that we abort ASAP. The return value of this command cannot be an error if the client successfully acknowledged some messages, so it should be executed in a "all or nothing" fashion.
-
- 23 2月, 2020 1 次提交
-
-
由 Guy Benoish 提交于
Use built-in alsoPropagate mechanism that wraps commands in MULTI/EXEC before sending them to replica/AOF
-
- 19 2月, 2020 1 次提交
-
-
由 Guy Benoish 提交于
-
- 08 1月, 2020 1 次提交
-
-
由 antirez 提交于
Fixes #6744.
-
- 30 12月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
This commit solves the following bug: 127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM OK 127.0.0.1:6379> XADD x 666 f v "666-0" 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) 1) 1) "666-0" 2) 1) "f" 2) "v" 127.0.0.1:6379> XADD x 667 f v "667-0" 127.0.0.1:6379> XDEL x 667 (integer) 1 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) (empty array) The root cause is that we use s->last_id in streamCompareID while we should use the last *valid* ID
-
- 26 12月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
This commit solves several edge cases that are related to exhausting the streamID limits: We should correctly calculate the succeeding streamID instead of blindly incrementing 'seq' This affects both XREAD and XADD. Other (unrelated) changes: Reply with a better error message when trying to add an entry to a stream that has exhausted last_id
-
- 18 12月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
-
- 19 11月, 2019 1 次提交
-
-
由 antirez 提交于
-
- 13 11月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
Calling XADD with 0-0 or 0 would result in creating an empty key and storing it in the database. Even worse, because XADD will reply with error the action will not be replicated, creating a master-replica inconsistency
-
- 06 11月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
Fixes GitHub issue #6492 Added stream support in RM_KeyType and RM_ValueLength. Also moduleDelKeyIfEmpty was updated, even though it has no effect now (It will be relevant when stream type direct API will be coded - i.e. RM_StreamAdd)
-
- 04 11月, 2019 2 次提交
- 10 10月, 2019 1 次提交
-
-
由 Guy Benoish 提交于
-
- 12 4月, 2019 1 次提交
-
-
由 James Rouzier 提交于
-
- 13 3月, 2019 1 次提交
-
-
由 Steve Webster 提交于
-
- 09 3月, 2019 1 次提交
-
-
由 Steve Webster 提交于
The XCLAIM docs state the XCLAIM increments the delivery counter for messages. This PR makes the code match the documentation - which seems like the desired behaviour - whilst still allowing RETRYCOUNT to be specified manually. My understanding of the way streamPropagateXCLAIM() works is that this change will safely propagate to replicas since retry count is pulled directly from the streamNACK struct. Fixes #5194
-
- 16 1月, 2019 1 次提交
-
-
由 zhaozhao.zz 提交于
Fix issue #5785, in case create group on a key is not stream.
-
- 10 1月, 2019 1 次提交
-
-
由 antirez 提交于
-
- 20 11月, 2018 1 次提交
-
-
由 antirez 提交于
This commit fixes #5570. It is a similar bug to one fixed a few weeks ago and is due to the range API to be called with NULL as "end ID" parameter instead of repeating again the start ID, to be sure that we selectively issue the entry with a given ID, or we get zero returned (and we know we should emit a NULL reply).
-
- 19 11月, 2018 2 次提交
- 05 11月, 2018 2 次提交
-
-
由 antirez 提交于
This bug had a double effect: 1. Sometimes entries may not be emitted, producing broken protocol where the array length was greater than the emitted entires, blocking the client waiting for more data. 2. Some other time the right entry was claimed, but a wrong entry was returned to the client. This fix should correct both the instances.
-
由 antirez 提交于
-
- 04 11月, 2018 1 次提交
-
-
由 michael-grunder 提交于
This fixes an overflow on 32-bit systems.
-
- 31 10月, 2018 1 次提交
-
-
由 Guy Korland 提交于
-
- 25 10月, 2018 2 次提交
- 24 10月, 2018 1 次提交
-
-
由 antirez 提交于
-
- 18 10月, 2018 1 次提交
-
-
由 Itamar Haber 提交于
-
- 17 10月, 2018 1 次提交
-
-
由 antirez 提交于
They play better with Lua scripting, otherwise Lua will see status replies as "ok" = "string" which is very odd, and actually as @oranagra reasoned in issue #5456 in the rest of the Redis code base there was no such concern as saving a few bytes when the protocol is emitted.
-