1. 06 Jul, 2016 1 commit
  2. 01 Jul, 2016 1 commit
  3. 30 Jun, 2016 1 commit
    • antirez's avatar
      In Redis RDB check: initial POC. · e97fadb0
      antirez authored
      So far we used an external program (later executed within Redis) and
      parser in order to check RDB files for correctness. This forces, at each
      RDB format update, to have two copies of the same format implementation
      that are hard to keep in sync. Morover the former RDB checker only
      checked the very high-level format of the file, without actually trying
      to load things in memory. Certain corruptions can only be handled by
      really loading key-value pairs.
      
      This first commit attempts to unify the Redis RDB loadig code with the
      task of checking the RDB file for correctness. More work is needed but
      it looks like a sounding direction so far.
      e97fadb0
  4. 16 Jun, 2016 1 commit
  5. 14 Jun, 2016 1 commit
  6. 08 Jun, 2016 1 commit
  7. 05 Jun, 2016 1 commit
  8. 28 May, 2016 1 commit
    • Itamar Haber's avatar
      Allow SPOP from Lua scripts · 2866e023
      Itamar Haber authored
      The existing `R` flag appears to be sufficient and there's no apparent reason why the command should be blocked.
      2866e023
  9. 10 May, 2016 2 commits
  10. 09 May, 2016 1 commit
  11. 05 May, 2016 5 commits
  12. 04 May, 2016 3 commits
  13. 22 Apr, 2016 1 commit
    • therealbill's avatar
      fix for #3187 · 14086a46
      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.
      14086a46
  14. 02 Mar, 2016 1 commit
  15. 26 Feb, 2016 1 commit
    • antirez's avatar
      BITFIELD command initial implementation. · 70af626d
      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
      70af626d
  16. 18 Feb, 2016 1 commit
  17. 03 Feb, 2016 1 commit
  18. 29 Jan, 2016 2 commits
  19. 26 Jan, 2016 1 commit
  20. 07 Jan, 2016 1 commit
    • antirez's avatar
      New security feature: Redis protected mode. · edd4d555
      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.
      edd4d555
  21. 17 Dec, 2015 2 commits
    • antirez's avatar
      Fix a race that may lead to the active (slave) client to be freed. · bb215375
      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.
      bb215375
    • antirez's avatar
      Fix processCommand() comment about return value. · 218e522c
      antirez authored
      218e522c
  22. 11 Dec, 2015 1 commit
  23. 27 Nov, 2015 1 commit
    • antirez's avatar
      Handle wait3() errors. · da827238
      antirez authored
      My guess was that wait3() with WNOHANG could never return -1 and an
      error. However issue #2897 may possibly indicate that this could happen
      under non clear conditions. While we try to understand this better,
      better to handle a return value of -1 explicitly, otherwise in the
      case a BGREWRITE is in progress but wait3() returns -1, the effect is to
      match the first branch of the if/else block since server.rdb_child_pid
      is -1, and call backgroundSaveDoneHandler() without a good reason, that
      will, in turn, crash the Redis server with an assertion.
      da827238
  24. 17 Nov, 2015 5 commits
  25. 10 Nov, 2015 1 commit
  26. 09 Nov, 2015 2 commits