1. 18 Dec, 2015 1 commit
  2. 17 Dec, 2015 1 commit
    • antirez's avatar
      Fix a race that may lead to the active (slave) client to be freed. · e0b7388d
      antirez authored
      In issue #2948 a crash was reported in processCommand(). Later Oran Agra
      (@oranagra) traced the bug (in private chat) in the following sequence
      of events:
      
      1. Some maxmemory is set.
      2. The slave is the currently active client and is executing PING or
         REPLCONF or whatever a slave can send to its master.
      3. freeMemoryIfNeeded() is called since maxmemory is set.
      4. flushSlavesOutputBuffers() is called by freeMemoryIfNeeded().
      5. During slaves buffers flush, a write error could be encoutered in
         writeToClient() or sendReplyToClient() depending on the version of
         Redis. This will trigger freeClient() against the currently active
         client, so a segmentation fault will likely happen in
         processCommand() immediately after the call to freeMemoryIfNeeded().
      
      There are different possible fixes:
      
      1. Add flags to writeToClient() (recent versions code base) so that
         we can ignore the write errors, and use this flag in
         flushSlavesOutputBuffers(). However this is not simple to do in older
         versions of Redis.
      2. Use freeClientAsync() during write errors. This works but changes the
         current behavior of releasing clients ASAP when possible. Normally
         we write to clients during the normal event loop processing, in the
         writable client, where there is no active client, so no care must be
         taken.
      3. The fix of this commit: to detect that the current client is no
         longer valid. This fix is a bit "ad-hoc", but works across all the
         versions and has the advantage of not changing the remaining
         behavior. Only alters what happens during this race condition,
         hopefully.
      e0b7388d
  3. 08 Sep, 2015 1 commit
  4. 16 Jul, 2015 1 commit
  5. 23 Dec, 2014 1 commit
    • antirez's avatar
      INFO loading stats: three fixes. · 22a0fe8d
      antirez authored
      1. Server unxtime may remain not updated while loading AOF, so ETA is
      not updated correctly.
      
      2. Number of processed byte was not initialized.
      
      3. Possible division by zero condition (likely cause of issue #1932).
      22a0fe8d
  6. 19 Dec, 2014 1 commit
  7. 13 Dec, 2014 2 commits
  8. 04 Dec, 2014 1 commit
  9. 03 Dec, 2014 2 commits
  10. 02 Dec, 2014 1 commit
    • antirez's avatar
      Mark PFCOUNT as read-only, even if not true. · 0e40124d
      antirez authored
      PFCOUNT is technically speaking a write command, since the cached value
      of the HLL is exposed in the data structure (design error, mea culpa), and
      can be modified by PFCOUNT.
      
      However if we flag PFCOUNT as "w", read only slaves can't execute the
      command, which is a problem since there are environments where slaves
      are used to scale PFCOUNT reads.
      
      Nor it is possible to just prevent PFCOUNT to modify the data structure
      in slaves, since without the cache we lose too much efficiency.
      
      So while this commit allows slaves to create a temporary inconsistency
      (the strings representing the HLLs in the master and slave can be
      different in certain moments) it is actually harmless.
      
      In the long run this should be probably fixed by turning the HLL into a
      more opaque representation, for example by storing the cached value in
      the part of the string which is not exposed (this should be possible
      with SDS strings).
      0e40124d
  11. 12 Nov, 2014 1 commit
  12. 29 Oct, 2014 5 commits
  13. 06 Oct, 2014 2 commits
  14. 16 Sep, 2014 1 commit
    • antirez's avatar
      Don't propagate SAVE. · fbd9dc60
      antirez authored
      This is a general fix (check that dirty delta is positive) but actually
      should have as the only effect fixing the SAVE propagation to
      AOF and slaves.
      fbd9dc60
  15. 08 Sep, 2014 1 commit
  16. 27 Aug, 2014 9 commits
  17. 18 Jul, 2014 3 commits
    • antirez's avatar
      06e9b3ca
    • antirez's avatar
      Variadic PING with support for Pub/Sub. · 70e39481
      antirez authored
      PING can now be called with an additional arugment, behaving exactly
      like the ECHO command. PING can now also be called in Pub/Sub mode (with
      one more more subscriptions to channels / patterns) in order to trigger
      the delivery of an asynchronous pong message with the optional payload.
      
      This fixes issue #420.
      70e39481
    • antirez's avatar
      PubSub clients refactoring and new PUBSUB flag. · 294bcfc4
      antirez authored
      The code tested many times if a client had active Pub/Sub subscriptions
      by checking the length of a list and dictionary where the patterns and
      channels are stored. This was substituted with a client flag called
      REDIS_PUBSUB that is simpler to test for. Moreover in order to manage
      this flag some code was refactored.
      
      This commit is believed to have no effects in the behavior of the
      server.
      294bcfc4
  18. 14 Jul, 2014 1 commit
    • michael-grunder's avatar
      Fix OBJECT arity · 3df2ab67
      michael-grunder authored
      Previously, the command definition for the OBJECT command specified
      a minimum of two args (and that it was variadic), which meant that
      if you sent this:
      
      OBJECT foo
      
      When cluster was enabled, it would result in an assertion/SEGFAULT
      when Redis was attempting to extract keys.
      
      It appears that OBJECT is not variadic, and only ever takes 3 args.
      
      https://gist.github.com/michael-grunder/25960ce1508396d0d36a
      3df2ab67
  19. 09 Jul, 2014 5 commits