- 10 May, 2016 3 commits
- 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.
-
- 16 Dec, 2015 2 commits
-
-
antirez authored
The old test, designed to do a transformation on the bits that was invertible, in order to avoid touching the original memory content, was not effective as it was redis-server --test-memory. The former often reported OK while the latter was able to spot the error. So the test was substituted with one that may perform better, however the new one must backup the memory tested, so it tests memory in small pieces. This limits the effectiveness because of the CPU caches. However some attempt is made in order to trash the CPU cache between the fill and the check stages, but not for the addressing test unfortunately. We'll see if this test will be able to find errors where the old failed.
-
antirez authored
-
- 11 Dec, 2015 1 commit
-
-
antirez authored
-
- 17 Nov, 2015 3 commits
- 05 Nov, 2015 2 commits
- 30 Oct, 2015 5 commits
-
-
antirez authored
Currently this feature is only accessible via DEBUG for testing, since otherwise depending on the instance configuration a given script works or is broken, which is against the Redis philosophy.
-
antirez authored
-
antirez authored
-
antirez authored
By calling redis.replicate_commands(), the scripting engine of Redis switches to commands replication instead of replicating whole scripts. This is useful when the script execution is costly but only results in a few writes performed to the dataset. Morover, in this mode, it is possible to call functions with side effects freely, since the script execution does not need to be deterministic: anyway we'll capture the outcome from the point of view of changes to the dataset. In this mode math.random() returns different sequences at every call. If redis.replicate_commnads() is not called before any other write, the command returns false and sticks to whole scripts replication instead.
-
antirez authored
-
- 21 Oct, 2015 1 commit
-
-
antirez authored
Sometimes it can be useful for clients to completely disable replies from the Redis server. For example when the client sends fire and forget commands or performs a mass loading of data, or in caching contexts where new data is streamed constantly. In such contexts to use server time and bandwidth in order to send back replies to clients, which are going to be ignored, is a shame. Multiple mechanisms are possible to implement such a feature. For example it could be a feature of MULTI/EXEC, or a command prefix such as "NOREPLY SADD myset foo", or a different mechanism that allows to switch on/off requests using the CLIENT command. The MULTI/EXEC approach has the problem that transactions are not strictly part of the no-reply semantics, and if we want to insert a lot of data in a bulk way, creating a huge MULTI/EXEC transaction in the server memory is bad. The prefix is the best in this specific use case since it does not allow desynchronizations, and is pretty clear semantically. However Redis internals and client libraries are not prepared to handle this currently. So the implementation uses the CLIENT command, providing a new REPLY subcommand with three options: CLIENT REPLY OFF disables the replies, and does not reply itself. CLIENT REPLY ON re-enables the replies, replying +OK. CLIENT REPLY SKIP only discards the reply of the next command, and like OFF does not reply anything itself. The reason to add the SKIP command is that it allows to have an easy way to send conceptually "single" commands that don't need a reply as the sum of two pipelined commands: CLIENT REPLY SKIP SET key value Note that CLIENT REPLY ON replies with +OK so it should be used when sending multiple commands that don't need a reply. However since it replies with +OK the client can check that the connection is still active and all the previous commands were received. This is currently just into Redis "unstable" so the proposal can be modified or abandoned based on users inputs.
-
- 15 Oct, 2015 1 commit
-
-
antirez authored
-
- 13 Oct, 2015 1 commit
-
-
antirez authored
This new function is able to restart the server "in place". The current Redis process executes the same executable it was executed with, using the same arguments and configuration file.
-
- 02 Oct, 2015 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 8 commits