- 05 3月, 2020 20 次提交
-
-
由 antirez 提交于
-
由 qetu3790 提交于
LRU_CYCLE_PERIOD is defined,but not used.
-
由 hwware 提交于
-
由 ShooterIT 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
The idea is that very few commands have a lot of keys, and when this happens the allocation time becomes neglegible.
-
由 Oran Agra 提交于
now that we may use it more often (ACL), these excessive calls to malloc and free can become an overhead.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Oran Agra 提交于
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.
-
由 Guy Benoish 提交于
-
由 Oran Agra 提交于
-
由 Oran Agra 提交于
-
由 Guy Benoish 提交于
-
由 antirez 提交于
This makes simpler to give people help when posting such kind of errors in the mailing list or other help forums, because sometimes the directive looks well spelled, but the version of Redis they are using is not able to support it.
-
- 28 2月, 2020 20 次提交
-
-
由 antirez 提交于
-
由 bodong.ybd 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Ponnuvel Palaniyappan 提交于
-
由 antirez 提交于
-
由 wangyuan21 提交于
-
由 srzhao 提交于
-
由 meir@redislabs.com 提交于
-
由 hwware 提交于
-
由 hwware 提交于
-
由 Hengjian Tang 提交于
-
由 Ariel 提交于
-
由 Guy Benoish 提交于
Use built-in alsoPropagate mechanism that wraps commands in MULTI/EXEC before sending them to replica/AOF
-
由 Oran Agra 提交于
in some cases we were trying to kill the fork before it got created
-
由 Guy Benoish 提交于
-
由 Oran Agra 提交于
it seems that running two clients at a time is ok too, resuces action time from 20 minutes to 10. we'll use this for now, and if one day it won't be enough we'll have to run just the sensitive tests one by one separately from the others. this commit also fixes an issue with the defrag test that appears to be very rare.
-
由 Oran Agra 提交于
seems that github actions are slow, using just one client to reduce false positives. also adding verbose, testing only on latest ubuntu, and building on older one. when doing that, i can reduce the test threshold back to something saner
-
由 Oran Agra 提交于
I saw that the new defag test for list was failing in CI recently, so i reduce it's threshold from 12 to 60. besides that, i add / improve the latency test for that other two defrag tests (add a sensitive latency and digest / save checks) and fix bad usage of debug populate (can't overrides existing keys). this was the original intention, which creates higher fragmentation.
-
由 antirez 提交于
-