- 30 Mar, 2018 1 commit
-
-
antirez authored
-
- 29 Mar, 2018 1 commit
-
-
antirez authored
-
- 28 Mar, 2018 1 commit
-
-
antirez authored
While this feature is not used by Redis, ae.c implements the ability for a timer to call a finalizer callback when an timer event is deleted. This feature was bugged since the start, and because it was never used we never noticed a problem. However Anthony LaTorre was using the same library in order to implement a different system: he found a bug that he describes as follows, and which he fixed with the patch in this commit, sent me by private email: --- Anthony email --- 've found one bug in the current implementation of the timed events. It's possible to lose track of a timed event if an event is added in the finalizerProc of another event. For example, suppose you start off with three timed events 1, 2, and 3. Then the linked list looks like: 3 -> 2 -> 1 Then, you run processTimeEvents and events 2 and 3 finish, so now the list looks like: -1 -> -1 -> 2 Now, on the next iteration of processTimeEvents it starts by deleting the first event, and suppose this finalizerProc creates a new event, so that the list looks like this: 4 -> -1 -> 2 On the next iteration of the while loop, when it gets to the second event, the variable prev is still set to NULL, so that the head of the event loop after the next event will be set to 2, i.e. after deleting the next event the event loop will look like: 2 and the event with id 4 will be lost. I've attached an example program to illustrate the issue. If you run it you will see that it prints: ``` foo id = 0 spam! ``` But if you uncomment line 29 and run it again it won't print "spam!". --- End of email --- Test.c source code is as follows: #include "ae.h" #include <stdio.h> aeEventLoop *el; int foo(struct aeEventLoop *el, long long id, void *data) { printf("foo id = %lld\n", id); return AE_NOMORE; } int spam(struct aeEventLoop *el, long long id, void *data) { printf("spam!\n"); return AE_NOMORE; } void bar(struct aeEventLoop *el, void *data) { aeCreateTimeEvent(el, 0, spam, NULL, NULL); } int main(int argc, char **argv) { el = aeCreateEventLoop(100); //aeCreateTimeEvent(el, 0, foo, NULL, NULL); aeCreateTimeEvent(el, 0, foo, NULL, bar); aeMain(el); return 0; } Anthony fixed the problem by using a linked list for the list of timers, and sent me back this patch after he tested the code in production for some time. The code looks sane to me, so committing it to Redis.
-
- 26 Mar, 2018 1 commit
-
-
antirez authored
-
- 25 Mar, 2018 2 commits
-
-
antirez authored
-
antirez authored
There are too many advantages in doing this, RDB is faster to persist, more compact, much faster to load back. The main issues here are that the code is less tested because this was not the old default (so we are enabling it for the new 5.0 release), and that the AOF is no longer a trivially parsable format from now on. However the non-preamble mode will be supported in the future as well, if new data types will be added.
-
- 23 Mar, 2018 2 commits
- 22 Mar, 2018 12 commits
-
-
Salvatore Sanfilippo authored
Update object.c
-
Salvatore Sanfilippo authored
Some commands will udpate lfu-counter many times in one call.
-
Salvatore Sanfilippo authored
Merge pull request #4722 from charsyam/feature/refactoring-call-aeDeleteFileEvent-twice-in-freeClusterLink Refactoring to call aeDeleteFileEvent twice as once
-
Salvatore Sanfilippo authored
anet: avoid double close
-
Salvatore Sanfilippo authored
Make blocking list commands send keyspace notifications
-
antirez authored
-
antirez authored
-
Guy Benoish authored
-
Salvatore Sanfilippo authored
fix listpack.c to listpack.o in Makefile
-
Salvatore Sanfilippo authored
fix missed dlclose leak in module.c
-
Salvatore Sanfilippo authored
Active defrag v2
-
Salvatore Sanfilippo authored
fix memory leak for streamPropagateXCLAIM
-
- 21 Mar, 2018 3 commits
-
-
charsyam authored
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 20 Mar, 2018 6 commits
-
-
antirez authored
This should be more than enough, even if in case of partial IDs that are not found, we send all the IDs to the slave/AOF, but this is definitely a corner case without bad effects if not some wasted space.
-
antirez authored
-
antirez authored
With XINFO out of the blue I invented a new syntax for commands never used in Redis in the past... Let's fix it and make it Great Again!!11one (TM)
-
antirez authored
-
antirez authored
-
antirez authored
-
- 19 Mar, 2018 1 commit
-
-
antirez authored
-
- 16 Mar, 2018 6 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
https://github.com/oertl/redisantirez authored
Merge branch 'hyperloglog-improvement' of https://github.com/oertl/redis into oertl-hyperloglog-improvement
-
antirez authored
-
antirez authored
-
- 15 Mar, 2018 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
This is a big win for caching use cases, since on reloading Redis will still have some idea about what is worth to evict and what not. However this only solves part of the problem because the information is only partially propagated to slaves (on write operations). Reads will not affect slaves LFU and LRU counters, so after a failover the eviction decisions are kinda random until keys start to collect some aging/freq info. However since new slaves are initially populated via RDB file transfer, this means that if we spin up a new slave from a master, and perform an immediate manual failover (for instance in order to upgrade the master), the slave will have eviction informations to use for some time. The LFU/LRU info is persisted only if the maxmemory policy is set to one of the relevant type, even if no actual "maxmemory" memory limit is set.
-