- 09 Nov, 2015 4 commits
-
-
antirez authored
-
antirez authored
The old version only flushed data to slaves if there were strings pending in the client->reply list. Now also static buffers are flushed. Does not help to free memory (which is the only use we have right now in the fuction), but is more correct conceptually, and may be used in other contexts.
-
antirez authored
Arguments arity and arguments type error of redis.call() were not reported correctly to Lua, so the command acted in this regard like redis.pcall(), but just for two commands. Redis.call() should always raise errors instead.
-
antirez authored
PING is now a valid command to issue in this context.
-
- 05 Nov, 2015 2 commits
- 04 Nov, 2015 11 commits
-
-
antirez authored
During the refactoring needed for lazy free, specifically the conversion of t_hash from struct robj to plain SDS strings, HINCRBFLOAT was accidentally moved away from long doubles to doubles for internal processing of increments and formatting. The diminished precision created more obvious artifacts in the way small numbers are formatted once we convert from decimal number in radix 10 to double and back to its string in radix 10. By using more precision, we now have less surprising results at least with small numbers like "1.23", exactly like in the previous versions of Redis. See issue #2846.
-
antirez authored
This test was kindly provided by Jan-Erik Rediger (@badboy here on Github) that discovered the issue. See issue #2846.
-
Salvatore Sanfilippo authored
Fix typo in READme sever/server
-
antirez authored
-
Joe Pettersson authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 03 Nov, 2015 1 commit
-
-
antirez authored
An user raised a question about a given behavior of PFCOUNT. Added a test to show the behavior (union) is correct when most of the items are in common.
-
- 30 Oct, 2015 13 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Make sure to flush the AOF output buffers before reloading. Result: less false timing related false positives on AOF tests.
-
antirez authored
-
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
This commit also inverts two stanzas of the code just becuase they are more logical like that, not because currently it makes any difference.
-
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
-
antirez authored
-
- 27 Oct, 2015 1 commit
-
-
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 4 commits
-
-
Salvatore Sanfilippo authored
Add copy & replace parameters to redis-trib import
-
antirez authored
-
antirez authored
-
antirez authored
-
- 14 Oct, 2015 2 commits
-
-
David Thomson authored
-
David Thomson authored
-
- 13 Oct, 2015 1 commit
-
-
antirez authored
-