1. 21 Jun, 2018 4 commits
  2. 20 Jun, 2018 1 commit
    • Guy Benoish's avatar
      Enhance RESTORE with RDBv9 new features · b5197f1f
      Guy Benoish authored
      RESTORE now supports:
      1. Setting LRU/LFU
      2. Absolute-time TTL
      
      Other related changes:
      1. RDB loading will not override LRU bits when RDB file
         does not contain the LRU opcode.
      2. RDB loading will not set LRU/LFU bits if the server's
         maxmemory-policy does not match.
      b5197f1f
  3. 19 Jun, 2018 8 commits
    • Oran Agra's avatar
      add malloc_usable_size for libc malloc · 482785ac
      Oran Agra authored
      this reduces the extra 8 bytes we save before each pointer.
      but more importantly maybe, it makes the valgrind runs to be more similiar
      to our normal runs.
      
      note: the change in malloc_stats struct in server.h is to eliminate an name conflict.
      structs that are not typedefed are resolved from a separate name space.
      482785ac
    • antirez's avatar
      4848fbec
    • Oran Agra's avatar
      fix redis-rdb-check to provide proper arguments to rdbLoadMillisecondTime · f31b0405
      Oran Agra authored
      due to incorrect forward declaration, it didn't provide all arguments.
      this lead to random value being read from the stack and return of incorrect time,
      which in this case doesn't matter since no one uses it.
      f31b0405
    • antirez's avatar
      AOF: remove no longer used variable "now". · 333c98c4
      antirez authored
      333c98c4
    • antirez's avatar
      e94b2053
    • Oran Agra's avatar
    • Oran Agra's avatar
      64 bit RDB_OPCODE_RESIZEDB in rdb saving · 5cd3c952
      Oran Agra authored
      this complication in the code is from times were rdbSaveLen didn't support 64 bits.
      5cd3c952
    • antirez's avatar
      Remove AOF optimization to skip expired keys. · ba92b517
      antirez authored
      Basically we cannot be sure that if the key is expired while writing the
      AOF, the main thread will surely find the key expired. There are
      possible race conditions like the moment at which the "now" is sampled,
      and the fact that time may jump backward.
      
      Think about the following:
      
      SET a 5
      EXPIRE a 1
      
      AOF rewrite starts after about 1 second. The child process finds the key
      expired, while in the main thread instead an INCR command is called
      against the key "a" immediately after a fork, and the scheduler was
      faster to give execution time to the main thread, so "a" is yet not
      expired.
      
      The main thread will generate an INCR a command to the AOF log that will
      be appended to the rewritten AOF file, but that INCR command will target
      a non existin "a" key, so a new non volatile key "a" will be created.
      
      Two observations:
      
      A) In theory by computing "now" before the fork, we should be sure that
      if a key is expired at that time, it will be expired later when the
      main thread will try to access to such key. However this does not take
      into account the fact that the computer time may jump backward.
      
      B) Technically we may still make the process safe by using a monotonic
      time source.
      
      However there were other similar related bugs, and in general the new
      "vision" is that Redis persistence files should represent the memory
      state without trying to be too smart: this makes the design more
      consistent, bugs less likely to arise from complex interactions, and in
      the end what is to fix is the Redis expire process to have less expired
      keys in RAM.
      
      Thanks to Oran Agra and Guy Benoish for writing me an email outlining
      this problem, after they conducted a Redis 5 code review.
      ba92b517
  4. 18 Jun, 2018 6 commits
  5. 17 Jun, 2018 1 commit
  6. 14 Jun, 2018 3 commits
    • antirez's avatar
      Sentinel: add an option to deny online script reconfiguration. · 6a66b93b
      antirez authored
      The ability of "SENTINEL SET" to change the reconfiguration script at
      runtime is a problem even in the security model of Redis: any client
      inside the network may set any executable to be ran once a failover is
      triggered.
      
      This option adds protection for this problem: by default the two
      SENTINEL SET subcommands modifying scripts paths are denied. However the
      user is still able to rever that using the Sentinel configuration file
      in order to allow such a feature.
      6a66b93b
    • antirez's avatar
      Fix infinite loop in dbRandomKey(). · d6e8fe77
      antirez authored
      Thanks to @kevinmcgehee for signaling the issue and reasoning about the
      consequences and potential fixes.
      
      Issue #5015.
      d6e8fe77
    • Fuxin Hao's avatar
      Fix update_zmalloc_stat_alloc in zrealloc · a4f658b2
      Fuxin Hao authored
      a4f658b2
  7. 13 Jun, 2018 4 commits
  8. 12 Jun, 2018 12 commits
  9. 11 Jun, 2018 1 commit
    • antirez's avatar
      Use a less aggressive query buffer resize policy. · cec404f0
      antirez authored
      A user with many connections (10 thousand) on a single Redis server
      reports in issue #4983 that sometimes Redis is idle becuase at the same
      time many clients need to resize their query buffer according to the old
      policy.
      
      It looks like this was created by the fact that we allow the query
      buffer to grow without problems to a size up to PROTO_MBULK_BIG_ARG
      normally, but when the client is idle we immediately are more strict,
      and a query buffer greater than 1024 bytes is already enough to trigger
      the resize. So for instance if most of the clients stop at the same time
      this issue should be easily triggered.
      
      This behavior actually looks odd, and there should be only a clear limit
      after we say, let's look at this query buffer to check if it's time to
      resize it. This commit puts the limit at PROTO_MBULK_BIG_ARG, and the
      check is performed both if compared to the peak usage the current usage
      is too big, or if the client is idle.
      
      Then when the check is performed, to waste just a few kbytes is
      considered enough to proceed with the resize. This should fix the issue.
      cec404f0