- 20 Jul, 2016 1 commit
-
-
antirez authored
-
- 15 Jul, 2016 1 commit
-
-
antirez authored
Implementation of LFU maxmemory policy for anything related to Redis objects. Still no actual eviction implemented.
-
- 13 Jul, 2016 1 commit
-
-
antirez authored
The LRU eviction code used to make local choices: for each DB visited it selected the best key to evict. This was repeated for each DB. However this means that there could be DBs with very frequently accessed keys that are targeted by the LRU algorithm while there were other DBs with many better candidates to expire. This commit attempts to fix this problem for the LRU policy. However the TTL policy is still not fixed by this commit. The TTL policy will be fixed in a successive commit. This is an initial (partial because of TTL policy) fix for issue #2647.
-
- 12 Jul, 2016 2 commits
- 06 Jul, 2016 1 commit
-
-
antirez authored
-
- 04 Jul, 2016 1 commit
-
-
antirez authored
We already changed the default in the redis.conf template, but I forgot to change the internal config as well.
-
- 01 Jul, 2016 1 commit
-
-
antirez authored
-
- 22 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 20 Jun, 2016 1 commit
-
-
Yossi Gottlieb authored
-
- 14 Jun, 2016 1 commit
-
-
antirez authored
-
- 13 Jun, 2016 2 commits
- 05 Jun, 2016 2 commits
-
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
-
- 03 Jun, 2016 1 commit
-
-
antirez authored
-
- 01 Jun, 2016 1 commit
-
-
antirez authored
-
- 18 May, 2016 1 commit
-
-
antirez authored
-
- 10 May, 2016 9 commits
- 09 May, 2016 1 commit
-
-
oranagra authored
-
- 25 Apr, 2016 1 commit
-
-
Oran Agra authored
-
- 22 Apr, 2016 1 commit
-
-
therealbill authored
I've renamed maxmemoryToString to evictPolicyToString since that is more accurate (and easier to mentally connect with the correct data), as well as updated the function to user server.maxmemory_policy rather than server.maxmemory. Now with a default config it is actually returning the correct policy rather than volatile-lru.
-
- 15 Apr, 2016 2 commits
- 14 Apr, 2016 1 commit
-
-
antirez authored
-
- 26 Feb, 2016 1 commit
-
-
antirez authored
The new bitfield command is an extension to the Redis bit operations, where not just single bit operations are performed, but the array of bits composing a string, can be addressed at random, not aligned offsets, with any width unsigned and signed integers like u8, s5, u10 (up to 64 bit signed integers and 63 bit unsigned integers). The BITFIELD command supports subcommands that can SET, GET, or INCRBY those arbitrary bit counters, with multiple overflow semantics. Trivial and credits: A similar command was imagined a few times in the past, but for some reason looked a bit far fetched or not well specified. Finally the command was proposed again in a clear form by Yoav Steinberg from Redis Labs, that proposed a set of commands on arbitrary sized integers stored at bit offsets. Starting from this proposal I wrote an initial specification of a single command with sub-commands similar to what Yoav envisioned, using short names for types definitions, and adding control on the overflow. This commit is the resulting implementation. Examples: BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
-
- 18 Feb, 2016 2 commits
- 29 Jan, 2016 3 commits
- 07 Jan, 2016 1 commit
-
-
antirez authored
An exposed Redis instance on the internet can be cause of serious issues. Since Redis, by default, binds to all the interfaces, it is easy to forget an instance without any protection layer, for error. Protected mode try to address this feature in a soft way, providing a layer of protection, but giving clues to Redis users about why the server is not accepting connections. When protected mode is enabeld (the default), and if there are no minumum hints about the fact the server is properly configured (no "bind" directive is used in order to restrict the server to certain interfaces, nor a password is set), clients connecting from external intefaces are refused with an error explaining what to do in order to fix the issue. Clients connecting from the IPv4 and IPv6 lookback interfaces are still accepted normally, similarly Unix domain socket connections are not restricted in any way.
-