- 10 Jun, 2020 9 commits
- 21 Apr, 2020 1 commit
-
-
antirez authored
-
- 02 Apr, 2020 1 commit
-
-
antirez authored
-
- 01 Apr, 2020 1 commit
-
-
Guy Benoish authored
By using a "circular BRPOPLPUSH"-like scenario it was possible the get the same client on db->blocking_keys twice (See comment in moduleTryServeClientBlockedOnKey) The fix was actually already implememnted in moduleTryServeClientBlockedOnKey but it had a bug: the funxction should return 0 or 1 (not OK or ERR) Other changes: 1. Added two commands to blockonkeys.c test module (To reproduce the case described above) 2. Simplify blockonkeys.c in order to make testing easier 3. cast raxSize() to avoid warning with format spec
-
- 31 Mar, 2020 2 commits
-
-
antirez authored
37a10cef introduced automatic wrapping of MULTI/EXEC for the alsoPropagate API. However this collides with the built-in mechanism already present in module.c. To avoid complex changes near Redis 6 GA this commit introduces the ability to exclude call() MUTLI/EXEC wrapping for also propagate in order to continue to use the old code paths in module.c.
-
antirez authored
-
- 23 Mar, 2020 1 commit
-
-
antirez authored
-
- 18 Mar, 2020 1 commit
-
-
Guy Benoish authored
-
- 28 Feb, 2020 2 commits
- 23 Feb, 2020 1 commit
-
-
Guy Benoish authored
-
- 22 Feb, 2020 2 commits
-
-
Ariel authored
-
chendianqiang authored
-
- 16 Feb, 2020 1 commit
-
-
Oran Agra authored
-
- 10 Feb, 2020 1 commit
-
-
meir@redislabs.com authored
-
- 06 Feb, 2020 4 commits
-
-
Oran Agra authored
-
Oran Agra authored
The callback approach we took is very efficient, the module can do any filtering of keys without building any list and cloning strings, it can also read data from the key's value. but if the user tries to re-open the key, or any other key, this can cause dict re-hashing (dictFind does that), and that's very bad to do from inside dictScan. this commit protects the dict from doing any rehashing during scan, but also warns the user not to attempt any writes or command calls from within the callback, for fear of unexpected side effects and crashes.
-
Oran Agra authored
using panic rather than exit means you get s stack trace of the code path that experianced the error, and possibly other info.
-
Oran Agra authored
currently there's no bug since the flags these functions handle are always lower than 32bit, but still better fix the type to prevent future bugs.
-
- 05 Feb, 2020 1 commit
-
-
Oran Agra authored
-
- 04 Feb, 2020 1 commit
-
-
Guy Benoish authored
-
- 03 Feb, 2020 2 commits
-
-
Oran Agra authored
-
Guy Benoish authored
Because "keymiss" is "special" compared to the rest of the notifications (Trying not to break existing apps using the 'A' format for notifications) Also updated redis.conf and module.c docs
-
- 30 Jan, 2020 1 commit
-
-
Guy Benoish authored
This bug affected RM_StringToLongDouble and HINCRBYFLOAT. I added tests for both cases. Main changes: 1. Fixed string2ld to fail if string contains \0 in the middle 2. Use string2ld in getLongDoubleFromObject - No point of having duplicated code here The two changes above broke RM_SaveLongDouble/RM_LoadLongDouble because the long double string was saved with length+1 (An innocent mistake, but it's actually a bug - The length passed to RM_SaveLongDouble should not include the last \0).
-
- 29 Jan, 2020 1 commit
-
-
antirez authored
-
- 30 Dec, 2019 1 commit
-
-
Guy Benoish authored
If a blocked module client times-out (or disconnects, unblocked by CLIENT command, etc.) we need to call moduleUnblockClient in order to free memory allocated by the module sub-system and blocked-client private data Other changes: Made blockedonkeys.tcl tests a bit more aggressive in order to smoke-out potential memory leaks
-
- 23 Dec, 2019 2 commits
-
-
Yossi Gottlieb authored
-
Oran Agra authored
-
- 20 Dec, 2019 1 commit
-
-
antirez authored
-
- 18 Dec, 2019 3 commits
-
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
-