summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge upstream 2.6.10.2.6.10-1Yossi Gottlieb2013-02-2519-42/+206
|\
| * Redis 2.6.102.6.10antirez2013-02-112-1/+22
| |
| * Makefile: valgrind target added (forces -O0 and libc malloc).antirez2013-02-111-1/+4
| |
| * TCP keep-alive. Better documentation in redis.conf.antirez2013-02-111-6/+11
| |
| * Tcp keep-alive: send three probes before detectin an error.antirez2013-02-111-4/+8
| | | | | | | | | | Otherwise we end with less reliable connections because it's too easy that a single packet gets lost.
| * tcp-keepalive option documented in redis.conf.antirez2013-02-111-0/+11
| |
| * Set SO_KEEPALIVE on client sockets if configured to do so.antirez2013-02-114-0/+14
| |
| * Add SO_KEEPALIVE support to anet.c.antirez2013-02-112-0/+44
| |
| * Sentinel: advertise the promoted slave address only after successful setup.antirez2013-02-111-1/+9
| |
| * fix comments forgotten in #285 (zipmap -> ziplist)Pierre Chapuis2013-02-112-3/+3
| |
| * Make all WATCHers dirty when the slave reloads the DB.antirez2013-02-081-0/+1
| |
| * LASTSAVE is a "random" command.antirez2013-02-071-1/+1
| |
| * TCP_NODELAY after SYNC: changes to the implementation.antirez2013-02-058-25/+39
| |
| * Turn off TCP_NODELAY on the slave socket after SYNC.charsyam2013-02-056-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Further details from @antirez: It was reported by @StopForumSpam on Twitter that the Redis replication link was strangely using multiple TCP packets for multiple commands. This wastes a lot of bandwidth and is due to the TCP_NODELAY option we enable on the socket after accepting a new connection. However the master -> slave channel is a one-way channel since Redis replication is asynchronous, so there is no point in trying to reduce the latency, we should aim to reduce the bandwidth. For this reason this commit introduces the ability to disable the nagle algorithm on the socket after a successful SYNC. This feature is off by default because the delay can be up to 40 milliseconds with normally configured Linux kernels.
| * Test: No clients timeout while testing.antirez2013-02-051-1/+1
| |
| * Use `info nameofexectuable` to find current executableJohan Bergström2013-02-053-3/+6
| |
| * Enforce tcl 8.5 or newerJohan Bergström2013-02-051-0/+2
| |
| * Check available tcl versionsJohan Bergström2013-02-051-5/+10
| |
| * retval doesn't initalizedRock Li2013-02-051-1/+1
| | | | | | | | If each if conditions are all fail, variable retval will under uninitlized
| * Fix a few typos and improve grammar of redis.confDavid Celis2013-02-041-18/+18
| | | | | | | | | | | | | | Make several edits to the example redis.conf configuration file for improved flow and grammar. Signed-off-by: David Celis <me@davidcel.is>
| * Fix a bug in srandmemberWithCountCommand()Gengliang Wang2013-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | In CASE 2, the call sunionDiffGenericCommand will involve the string "srandmember" > sadd foo one (integer 1) > sadd srandmember two (integer 2) > srandmember foo 3 1)"one" 2)"two"
* | Merge upstream Redis 2.6.9.2.6.9-1Yossi Gottlieb2013-01-2746-225/+512
|\ \ | |/
| * Lua struct library updated to version 0.2.antirez2013-01-231-52/+119
| | | | | | | | | | | | | | | | | | | | | | | | There was a bug in the previous version of this library that caused a crash under the circumstances described in issue #901. The newer version of the library appears to be fixed (I tested it manually with valgrind and everything seems fine now). For more information about this library please visit this web site: http://www.inf.puc-rio.br/~roberto/struct/
| * redis-cli --bigkeys output is now simpler to understand.antirez2013-01-211-2/+4
| |
| * UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply.antirez2013-01-212-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe the client respectively all the channels and patters if called without arguments. However when these functions are called without arguments, but there are no channels or patters we are subscribed to, the old behavior was to don't reply at all. This behavior is broken, as every command should always reply. Also it is possible that we are no longer subscribed to a channels but we are subscribed to patters or the other way around, and the client should be notified with the correct number of subscriptions. Also it is not pretty that sometimes we did not receive a reply at all in a redis-cli session from these commands, blocking redis-cli trying to read the reply. This fixes issue #714.
| * Fixed a bug in memtest progress bar, that had no actual effects.antirez2013-01-211-4/+2
| | | | | | | | This closes issue #859, thanks to @erbenmo.
| * Not every __sun has backtrace().antirez2013-01-211-1/+1
| | | | | | | | | | | | I don't know how to test for Open Solaris that has support for backtrace() so for now removing the #ifdef that breaks compilation under other Solaris flavors.
| * Additionally two typos fixed thanks to @jodalantirez2013-01-192-2/+2
| |
| * Whitelist SIGUSR1 to avoid auto-triggering errors.antirez2013-01-194-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes issue #875 that was caused by the following events: 1) There is an active child doing BGSAVE. 2) flushall is called (or any other condition that makes Redis killing the saving child process). 3) An error is sensed by Redis as the child exited with an error (killed by a singal), that stops accepting write commands until a BGSAVE happens to be executed with success. Whitelisting SIGUSR1 and making sure Redis always uses this signal in order to kill its own children fixes the issue.
| * Clear server.shutdown_asap on failed shutdown.antirez2013-01-191-0/+1
| | | | | | | | | | | | | | When a SIGTERM is received Redis schedules a shutdown. However if it fails to perform the shutdown it must be clear the shutdown_asap flag otehrwise it will try again and again possibly making the server unusable.
| * Slowlog: don't log EXEC but just the executed commands.antirez2013-01-192-1/+13
| | | | | | | | | | | | | | | | | | | | The Redis Slow Log always used to log the slow commands executed inside a MULTI/EXEC block. However also EXEC was logged at the end, which is perfectly useless. Now EXEC is no longer logged and a test was added to test this behavior. This fixes issue #759.
| * Fixed many typos.guiquanz2013-01-1938-137/+137
| |
| * redis-cli prompt bug fixcharsyam2013-01-191-0/+1
| |
| * Always exit if connection fails.Jan-Erik Rediger2013-01-191-4/+4
| | | | | | | | This avoids unnecessary core dumps. Fixes antirez/redis#894
| * Fix an error reply for CLIENT commandbitterb2013-01-191-1/+1
| |
| * redis-cli --rdb fails if server sends a pingNathan Parry2013-01-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redis pings slaves in "pre-synchronization stage" with newlines. (See https://github.com/antirez/redis/blob/2.6.9/src/replication.c#L814) However, redis-cli does not expect this - it sees the newline as the end of the bulk length line, and ends up returning 0 as bulk the length. This manifests as the following when running redis-cli: $ ./src/redis-cli --rdb some_file SYNC sent to master, writing 0 bytes to 'some_file' Transfer finished with success. With this commit, we just ignore leading newlines while reading the bulk length line. To reproduce the problem, load enough data into Redis so that the preparation of the RDB snapshot takes long enough for a ping to occur while redis-cli is waiting for the data.
| * Redis 2.6.92.6.9antirez2013-01-162-1/+15
| |
| * redis-cli: save an RDB dump from remote server to local file.antirez2013-01-161-8/+81
| |
| * Tests for CLIENT GETNAME/SETNAME.antirez2013-01-151-0/+33
| |
| * Typo fixed, ASCI -> ASCII.antirez2013-01-151-1/+1
| |
| * CLIENT GETNAME and CLIENT SETNAME introduced.antirez2013-01-153-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes it is much simpler to debug complex Redis installations if it is possible to assign clients a name that is displayed in the CLIENT LIST output. This is the case, for example, for "leaked" connections. The ability to provide a name to the client makes it quite trivial to understand what is the part of the code implementing the client not releasing the resources appropriately. Behavior: CLIENT SETNAME: set a name for the client, or remove the current name if an empty name is set. CLIENT GETNAME: get the current name, or a nil. CLIENT LIST: now displays the client name if any. Thanks to Mark Gravell for pushing this idea forward.
| * Undo slave-master handshake when SLAVEOF sets a new slave.antirez2013-01-151-7/+23
| | | | | | | | | | | | | | | | | | | | | | Issue #828 shows how Redis was not correctly undoing a non-blocking connection attempt with the previous master when the master was set to a new address using the SLAVEOF command. This was also a result of lack of refactoring, so now there is a function to cancel the non blocking handshake with the master. The new function is now used when SLAVEOF NO ONE is called or when SLAVEOF is used to set the master to a different address.
* | Merge upstream Redis 2.6.8.2.6.8-1Yossi Gottlieb2013-01-1518-40/+186
|\ \ | |/
| * Makefile.dep updated.antirez2013-01-111-4/+13
| |
| * Redis 2.6.82.6.8antirez2013-01-102-1/+12
| |
| * Comment in the call() function clarified a bit.antirez2013-01-101-2/+3
| |
| * Test: added regression for issue #872.antirez2013-01-101-7/+27
| |
| * Multiple fixes for EVAL (issue #872).antirez2013-01-101-20/+21
| | | | | | | | | | | | | | | | 1) The event handler was no restored after a timeout condition if the command was eventually executed with success. 2) The command was not converted to EVAL in case of errors in the middle of the execution. 3) Terrible duplication of code without any apparent reason.
| * Better error reporting when fd event creation fails.antirez2013-01-032-2/+6
| |
| * ae.c: set errno when error is not a failing syscall.antirez2013-01-031-1/+5
| | | | | | | | | | | | In this way the caller is able to perform better error checking or to use strerror() without the risk of meaningless error messages being displayed.
View Lorry Controller Status