- 31 Mar, 2014 2 commits
- 30 Mar, 2014 2 commits
-
-
antirez authored
The more we add elements to an HyperLogLog counter, the smaller is the probability that we actually update some register. From this observation it is easy to see how it is possible to use caching of a previously computed cardinality and reuse it to serve HLLCOUNT queries as long as no register was updated in the data structure. This commit does exactly this by using just additional 8 bytes for the data structure to store a 64 bit unsigned integer value cached cardinality. When the most significant bit of the 64 bit integer is set, it means that the value computed is no longer usable since at least a single register was modified and we need to recompute it at the next call of HLLCOUNT. The value is always stored in little endian format regardless of the actual CPU endianess.
-
antirez authored
All the Redis functions that need to modify the string value of a key in a destructive way (APPEND, SETBIT, SETRANGE, ...) require to make the object unshared (if refcount > 1) and encoded in raw format (if encoding is not already REDIS_ENCODING_RAW). This was cut & pasted many times in multiple places of the code. This commit puts the small logic needed into a function called dbUnshareStringValue().
-
- 29 Mar, 2014 5 commits
-
-
antirez authored
We need to be sure that you can save a dataset in a Redis instance, reload it in a different architecture, and continue to count in the same HyperLogLog structure. So 32 and 64 bit, little or bit endian, must all guarantee to output the same hash for the same element.
-
antirez authored
The new representation is more obvious, starting from the LSB of the first byte and using bits going to MSB, and passing to next byte as needed. There was also a subtle error: first two bits were unused, everything was carried over on the right of two bits, even if it worked because of the code requirement of always having a byte more at the end. During the rewrite the code was made safer trying to avoid undefined behavior due to shifting an uint8_t for more than 8 bits.
-
antirez authored
-
antirez authored
-
antirez authored
This speedups the macros by a noticeable factor.
-
- 28 Mar, 2014 13 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
There was an error in the computation of 2^register, and the sequence of zeroes computed after the hashing did not included the "1".
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
There was an error in the first version of the macro. Now the HLLSELFTEST test reports success.
-
antirez authored
-
antirez authored
-
antirez authored
To test the bitfield array of counters set/get macros from the Redis Tcl suite is hard, so a specialized command that is able to test the internals was developed.
-
antirez authored
-
- 27 Mar, 2014 2 commits
- 26 Mar, 2014 3 commits
-
-
antirez authored
This is not really an error but something that always happens for example when creating a new cluster, or if the sysadmin rejoins manually a node that is already known. Since useless logs don't help, moved to VERBOSE level.
-
antirez authored
New config epochs must always be obtained incrementing the currentEpoch, that is itself guaranteed to be >= the max configEpoch currently known to the node.
-
antirez authored
-
- 25 Mar, 2014 8 commits
-
-
antirez authored
Update the comment since the implementation details changed.
-
antirez authored
redis-trib used to allocate slots not considering fractions of nodes when computing the slots_per_node amount. So the fractional part was carried over till the end of the allocation, where the last node received a few more slots than any other (or a lot more if the cluster was composed of many nodes). The computation was changed to allocate slots more evenly when they are not exactly divisible for the number of masters we have.
-
antirez authored
The slave election in Redis Cluster guarantees that slaves promoted to masters always end with unique config epochs, however failures during manual reshardings, software bugs and operational errors may in theory cause two nodes to have the same configEpoch. This commit introduces a mechanism to eventually always end with different configEpochs if a collision ever happens. As a (wanted) side effect, this also ensures that after a new cluster is created, all nodes will end with a different configEpoch automatically.
-
antirez authored
-
antirez authored
Bug found by the continuous integration test running the Redis with valgrind: ==6245== Invalid read of size 8 ==6245== at 0x4C2DEEF: memcpy@GLIBC_2.2.5 (mc_replace_strmem.c:876) ==6245== by 0x41F9E6: freeMemoryIfNeeded (redis.c:3010) ==6245== by 0x41D2CC: processCommand (redis.c:2069) memmove() size argument was accounting for an extra element, going outside the bounds of the array.
-
antirez authored
-
antirez authored
In this commit: * Decrement steps are semantically differentiated from the reserved FDs. Previously both values were 32 but the meaning was different. * Make it clear that we save setrlimit errno. * Don't explicitly handle wrapping of 'f', but prevent it from happening. * Add comments to make the function flow more readable. This integrates PR #1630
-
Salvatore Sanfilippo authored
Fix infinite loop ulimit
-
- 24 Mar, 2014 5 commits
-
-
antirez authored
In sentinelFlushConfig() fd could be undefined when the following if statement was true: if (rewrite_status == -1) goto werr; This could cause random file descriptors to get closed.
-
Salvatore Sanfilippo authored
Use LRU_CLOCK() instead of function getLRUClock()
-
Matt Stancliff authored
lookupKey() uses LRU_CLOCK(), so it seems object creation should use LRU_CLOCK() too.
-
Salvatore Sanfilippo authored
Fix data loss when save AOF/RDB with no free space
-
Matt Stancliff authored
-