- 04 Oct, 2021 1 commit
-
-
Oran Agra authored
- fix possible heap corruption in ziplist and listpack resulting by trying to allocate more than the maximum size of 4GB. - prevent ziplist (hash and zset) from reaching size of above 1GB, will be converted to HT encoding, that's not a useful size. - prevent listpack (stream) from reaching size of above 1GB. - XADD will start a new listpack if the new record may cause the previous listpack to grow over 1GB. - XADD will respond with an error if a single stream record is over 1GB - List type (ziplist in quicklist) was truncating strings that were over 4GB, now it'll respond with an error.
-
- 22 Feb, 2021 1 commit
-
-
zhaozhao.zz authored
This bug would have let users observe logically expired keys on replicas and during CLIENT PAUSE WRITE. (cherry picked from commit f2a5fe36)
-
- 27 Oct, 2020 1 commit
-
-
Oran Agra authored
List of squashed commits or PRs =============================== commit 66801ea Author: hwware <wen.hui.ware@gmail.com> Date: Mon Jan 13 00:54:31 2020 -0500 typo fix in acl.c commit 46f55db Author: Itamar Haber <itamar@redislabs.com> Date: Sun Sep 6 18:24:11 2020 +0300 Updates a couple of comments Specifically: * RM_AutoMemory completed instead of pointing to docs * Updated link to custom type doc commit 61a2aa0 Author: xindoo <xindoo@qq.com> Date: Tue Sep 1 19:24:59 2020 +0800 Correct errors in code comments commit a5871d1 Author: yz1509 <pro-756@qq.com> Date: Tue Sep 1 18:36:06 2020 +0800 fix typos in module.c commit 41eede7 Author: bookug <bookug@qq.com> Date: Sat Aug 15 01:11:33 2020 +0800 docs: fix typos in comments commit c303c84 Author: lazy-snail <ws.niu@outlook.com> Date: Fri Aug 7 11:15:44 2020 +0800 fix spelling in redis.conf commit 1eb76bf Author: zhujian <zhujianxyz@gmail.com>...
-
- 01 Sep, 2020 1 commit
-
- 20 Jul, 2020 1 commit
-
- 08 May, 2020 1 commit
-
-
Guy Benoish authored
Same goes for XGROUP DELCONSUMER (But in this case, it doesn't have any visible effect)
-
- 30 Apr, 2020 2 commits
-
-
Guy Benoish authored
-
Guy Benoish authored
Introducing XINFO STREAM <key> FULL
-
- 24 Apr, 2020 4 commits
-
-
antirez authored
-
antirez authored
-
Valentino Geron authored
-
antirez authored
-
- 17 Apr, 2020 1 commit
-
-
antirez authored
See issue #7105.
-
- 15 Apr, 2020 1 commit
-
-
antirez authored
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
-
- 07 Apr, 2020 3 commits
-
-
Valentino Geron authored
-
Valentino Geron authored
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.
-
Guy Benoish authored
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
-
- 05 Mar, 2020 1 commit
-
-
Guy Benoish authored
-
- 27 Feb, 2020 2 commits
-
-
Guy Benoish authored
Use built-in alsoPropagate mechanism that wraps commands in MULTI/EXEC before sending them to replica/AOF
-
Guy Benoish authored
-
- 10 Jan, 2020 1 commit
-
-
Guy Benoish authored
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
-
- 08 Jan, 2020 1 commit
-
-
antirez authored
Fixes #6744.
-
- 29 Dec, 2019 1 commit
-
-
Guy Benoish authored
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
-
- 19 Nov, 2019 1 commit
-
-
antirez authored
-
- 13 Nov, 2019 1 commit
-
-
Guy Benoish authored
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 Nov, 2019 1 commit
-
-
Guy Benoish authored
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 Nov, 2019 2 commits
- 10 Oct, 2019 1 commit
-
-
Guy Benoish authored
-
- 11 Apr, 2019 1 commit
-
-
James Rouzier authored
-
- 12 Mar, 2019 1 commit
-
-
Steve Webster authored
-
- 08 Mar, 2019 1 commit
-
-
Steve Webster authored
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 Jan, 2019 1 commit
-
-
zhaozhao.zz authored
Fix issue #5785, in case create group on a key is not stream.
-
- 09 Jan, 2019 1 commit
-
-
antirez authored
-
- 19 Nov, 2018 3 commits
-
-
antirez authored
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).
-
antirez authored
This fixes the issue reported in #5570. This was fixed the hard way, that is, propagating more information to the lower level API about this being a request to read just the history, so that the code is simpler and less likely to regress.
-
antirez authored
-
- 05 Nov, 2018 2 commits
-
-
antirez authored
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 authored
-
- 03 Nov, 2018 1 commit
-
-
michael-grunder authored
This fixes an overflow on 32-bit systems.
-