- 09 10月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 04 10月, 2013 4 次提交
-
-
由 antirez 提交于
Sometimes when we resurrect a cached master after a successful partial resynchronization attempt, there is pending data in the output buffers of the client structure representing the master (likely REPLCONF ACK commands). If we don't reinstall the write handler, it will never be installed again by addReply*() family functions as they'll assume that if there is already data pending, the write handler is already installed. This bug caused some slaves after a successful partial sync to never send REPLCONF ACK, and continuously being detected as timing out by the master, with a disconnection / reconnection loop.
-
由 antirez 提交于
Since we started sending REPLCONF ACK from slaves to masters, the lastinteraction field of the client structure is always refreshed as soon as there is room in the socket output buffer, so masters in timeout are detected with too much delay (the socket buffer takes a lot of time to be filled by small REPLCONF ACK <number> entries). This commit only counts data received as interactions with a master, solving the issue.
-
由 antirez 提交于
There was a bug that over-esteemed the amount of backlog available, however this could only happen when a slave was asking for an offset that was in the "future" compared to the master replication backlog. Now this case is handled well and logged as an incident in the master log file.
-
由 antirez 提交于
-
- 26 9月, 2013 1 次提交
-
-
由 Michel Martens 提交于
-
- 17 9月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 04 9月, 2013 1 次提交
-
-
由 antirez 提交于
The code freed a reply object that was never created, resulting in a segfault every time randomkey returned a key that was deleted before we queried it for size.
-
- 03 9月, 2013 2 次提交
-
-
由 Maxim Zakharov 提交于
-
由 Maxim Zakharov 提交于
-
- 30 8月, 2013 3 次提交
- 29 8月, 2013 1 次提交
-
-
由 antirez 提交于
Multiple missing calls to lua_pop prevented the error handler function pushed on the stack for lua_pcall() to be popped before returning, causing a memory leak in almost all the code paths of EVAL (both successful calls and calls returning errors). This caused two issues: Lua leaking memory (and this was very visible from INFO memory output, as the 'used_memory_lua' field reported an always increasing amount of memory used), and as a result slower and slower GC cycles resulting in all the CPU being used. Thanks to Tanguy Le Barzic for noticing something was wrong with his 2.8 slave, and for creating a testing EC2 environment where I was able to investigate the issue.
-
- 27 8月, 2013 9 次提交
-
-
由 Salvatore Sanfilippo 提交于
fix lua_cmsgpack pack map as array
-
由 antirez 提交于
-
由 antirez 提交于
When no encoding is possible, at least try to reallocate the sds string with one that does not waste memory (with free space at the end of the buffer) when the string is large enough.
-
由 antirez 提交于
We are sure that a string that is longer than 21 chars cannot be represented by a 64 bit signed integer, as -(2^64) is 21 chars: strlen(-18446744073709551616) => 21
-
由 antirez 提交于
-
由 antirez 提交于
The call to sdsMakeRoomFor() did not accounted for the amount of data already present in the query buffer, resulting into over-allocation.
-
由 antirez 提交于
This command is only useful for low-level debugging of memory issues due to sds wasting memory as empty buffer at the end of the string.
-
由 antirez 提交于
-
由 antirez 提交于
-
- 22 8月, 2013 2 次提交
- 21 8月, 2013 4 次提交
- 20 8月, 2013 3 次提交
- 19 8月, 2013 8 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Also a warning was suppressed by including unistd.h in redisassert.h (needed for _exit()).
-
由 antirez 提交于
By using redisassert.h version of assert() you get stack traces in the log instead of a process disappearing on assertions.
-
由 antirez 提交于
The previous hashing used the trivial algorithm of xoring the integers together. This is not optimal as it is very likely that different hash table setups will hash the same, for instance an hash table at the start of the rehashing process, and at the end, will have the same fingerprint. Now we hash N integers in a smarter way, by summing every integer to the previous hash, and taking the integer hashing again (see the code for further details). This way it is a lot less likely that we get a collision. Moreover this way of hashing explicitly protects from the same set of integers in a different order to hash to the same number. This commit is related to issue #1240.
-
由 antirez 提交于
Related to issue #1240.
-
由 antirez 提交于
This commit does mainly two things: 1) It fixes zunionInterGenericCommand() by removing mass-initialization of all the iterators used, so that we don't violate the unsafe iterator API of dictionaries. This fixes issue #1240. 2) Since the zui* APIs required the allocator to be initialized in the zsetopsrc structure in order to use non-iterator related APIs, this commit fixes this strict requirement by accessing objects directly via the op->subject->ptr pointer we have to the object.
-
由 antirez 提交于
dict.c allows the user to create unsafe iterators, that are iterators that will not touch the dictionary data structure in any way, preventing copy on write, but at the same time are limited in their usage. The limitation is that when itearting with an unsafe iterator, no call to other dictionary functions must be done inside the iteration loop, otherwise the dictionary may be incrementally rehashed resulting into missing elements in the set of the elements returned by the iterator. However after introducing this kind of iterators a number of bugs were found due to misuses of the API, and we are still finding bugs about this issue. The bugs are not trivial to track because the effect is just missing elements during the iteartion. This commit introduces auto-detection of the API misuse. The idea is that an unsafe iterator has a contract: from initialization to the release of the iterator the dictionary should not change. So we take a fingerprint of the dictionary state, xoring a few important dict properties when the unsafe iteartor is initialized. We later check when the iterator is released if the fingerprint is still the same. If it is not, we found a misuse of the iterator, as not allowed API calls changed the internal state of the dictionary. This code was checked against a real bug, issue #1240. This is what Redis prints (aborting) when a misuse is detected: Assertion failed: (iter->fingerprint == dictFingerprint(iter->d)), function dictReleaseIterator, file dict.c, line 587.