- 28 Oct, 2019 2 commits
-
-
swilly22 authored
Introduce ReplyWithVerbatimString, ReplyWithEmptyArray, ReplyWithNullArray and ReplyWithEmptyString to redis module API
-
zhaozhao.zz authored
As we know if a module exports module-side data types, unload it is not allowed. This rule is the same with blocked clients in module, because we use background threads to implement module blocked clients, and it's not safe to unload a module if there are background threads running. So it's necessary to check if any blocked clients running in this module when unload it. Moreover, after that we can ensure that if no modules, then no module blocked clients even module unloaded. So, we can call moduleHandleBlockedClients only when we have installed modules.
-
- 25 Oct, 2019 1 commit
-
-
happynote3966 authored
-
- 24 Oct, 2019 1 commit
-
-
antirez authored
-
- 23 Oct, 2019 26 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
We can't use the same client at the same time when re-entering the hook.
-
antirez authored
-
antirez authored
Calling a module hook callback may result in callback operations in turn triggering other events the module is subscribed too. We don't want to trigger those, it's unsafe and quite confusing, and to do it correcly we would need to maintain an event list: quite a more complex implementation.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
In 32 bit systems casting to "long" will cut the result to 32 bit.
-
- 17 Oct, 2019 3 commits
- 16 Oct, 2019 1 commit
-
-
Yossi Gottlieb authored
-
- 15 Oct, 2019 3 commits
-
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
-
- 10 Oct, 2019 2 commits
-
-
antirez authored
This is what happened: 1. Instance starts, is a slave in the cluster configuration, but actually server.masterhost is not set, so technically the instance is acting like a master. 2. loadDataFromDisk() calls replicationCacheMasterUsingMyself() even if the instance is a master, in the case it is logically a slave and the cluster is enabled. So now we have a cached master even if the instance is practically configured as a master (from the POV of server.masterhost value and so forth). 3. clusterCron() sees that the instance requires to replicate from its master, because logically it is a slave, so it calls replicationSetMaster() that will in turn call replicationCacheMasterUsingMyself(): before this commit, this call would overwrite the old cached master, creating a memory leak.
-
Guy Benoish authored
-
- 09 Oct, 2019 1 commit
-
-
omg-by authored
-