- 19 Jun, 2017 1 commit
-
-
antirez authored
-
- 15 Jun, 2017 1 commit
-
-
antirez authored
-
- 14 Jun, 2017 2 commits
- 13 Jun, 2017 3 commits
-
-
Salvatore Sanfilippo authored
Fixed comment in clusterMsg version field
-
Salvatore Sanfilippo authored
Removed duplicate 'sys/socket.h' include
-
antirez authored
-
- 04 Jun, 2017 2 commits
-
-
Antonio Mallia authored
-
Antonio Mallia authored
-
- 19 May, 2017 2 commits
- 15 May, 2017 1 commit
-
-
antirez authored
Close #3993.
-
- 10 May, 2017 3 commits
-
-
antirez authored
-
antirez authored
This avoids Helgrind complaining, but we are actually not using atomicGet() to get the unixtime value for now: too many places where it is used and given tha time_t is word-sized it should be safe in all the archs we support as it is. On the other hand, Helgrind, when Redis is compiled with "make helgrind" in order to force the __sync macros, will detect the write in updateCachedTime() as a read (because atomic functions are used) and will not complain about races. This commit also includes minor refactoring of mutex initializations and a "helgrind" target in the Makefile.
-
antirez authored
The __sync builtin can be correctly detected by Helgrind so to force it is useful for testing. The API in the INFO output can be useful for debugging after problems are reported.
-
- 09 May, 2017 3 commits
- 04 May, 2017 2 commits
- 03 May, 2017 8 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Instead of giving the module background operations just a small time to run in the beforeSleep() function, we can have the lock released for all the time we are blocked in the multiplexing syscall.
-
- 02 May, 2017 3 commits
- 28 Apr, 2017 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Experimentally verified that it can trigger the issue reverting the fix. At least on my system... Being the bug time/backlog dependant, it is very hard to tell if this test will be able to trigger the problem consistently, however even if it triggers the problem once in a while, we'll see it in the CI environment at http://ci.redis.io.
-
- 27 Apr, 2017 1 commit
-
-
antirez authored
The master client cleanup was incomplete: resetClient() was missing and the output buffer of the client was not reset, so pending commands related to the previous connection could be still sent. The first problem caused the client argument vector to be, at times, half populated, so that when the correct replication stream arrived the protcol got mixed to the arugments creating invalid commands that nobody called. Thanks to @yangsiran for also investigating this problem, after already providing important design / implementation hints for the original PSYNC2 issues (see referenced Github issue). Note that this commit adds a new function to the list library of Redis in order to be able to reset a list without destroying it. Related to issue #3899.
-
- 22 Apr, 2017 4 commits
-
-
antirez authored
Related to #3786.
-
antirez authored
Apparently 1.4 is too low compared to what you get in certain setups (including mine). I raised it to 1.55 that hopefully is still enough to test that the fragmentation went down from 1.7 but without incurring in issues, however the test setup may be still fragile so certain times this may lead to false positives again, it's hard to test for these things in a determinsitic way. Related to #3786.
-
oranagra authored
-
- 21 Apr, 2017 1 commit
-
-
antirez authored
Normally we never check for OOM conditions inside Redis since the allocator will always return a pointer or abort the program on OOM conditons. However we cannot have control on epool_create(), that may fail for kernel OOM (according to the manual page) even if all the parameters are correct, so the function aeCreateEventLoop() may indeed return NULL and this condition must be checked.
-