1. 11 Jul, 2017 1 commit
  2. 23 Feb, 2017 1 commit
  3. 19 Feb, 2017 2 commits
  4. 16 Dec, 2016 3 commits
  5. 27 Jul, 2015 1 commit
  6. 26 Jul, 2015 5 commits
  7. 10 Dec, 2014 1 commit
    • antirez's avatar
      Better read-only behavior for expired keys in slaves. · 06e76bc3
      antirez authored
      Slaves key expire is orchestrated by the master. Sometimes the master
      will send the synthesized DEL to expire keys on the slave with a non
      trivial delay (when the key is not accessed, only the incremental expiry
      algorithm will expire it in background).
      
      During that time, a key is logically expired, but slaves still return
      the key if you GET (or whatever) it. This is a bad behavior.
      
      However we can't simply trust the slave view of the key, since we need
      the master to be able to send write commands to update the slave data
      set, and DELs should only happen when the key is expired in the master
      in order to ensure consistency.
      
      However 99.99% of the issues with this behavior is when a client which
      is not a master sends a read only command. In this case we are safe and
      can consider the key as non existing.
      
      This commit does a few changes in order to make this sane:
      
      1. lookupKeyRead() is modified in order to return NULL if the above
      conditions are met.
      2. Calls to lookupKeyRead() in commands actually writing to the data set
      are repliaced with calls to lookupKeyWrite().
      
      There are redundand checks, so for example, if in "2" something was
      overlooked, we should be still safe, since anyway, when the master
      writes the behavior is to don't care about what expireIfneeded()
      returns.
      
      This commit is related to  #1768, #1770, #2131.
      06e76bc3
  8. 02 Dec, 2014 1 commit
  9. 13 Aug, 2014 1 commit
  10. 23 Jul, 2014 1 commit
    • antirez's avatar
      PFSELFTEST: less false positives. · 0adf4482
      antirez authored
      This is just a quickfix, for the nature of the test the right way to fix
      it is to average the error of N runs, since otherwise it is always
      possible to get a false positive with a bad run, or to minimize too much
      this possibility we may end testing with too much "large" error ranges.
      0adf4482
  11. 18 May, 2014 1 commit
  12. 17 Apr, 2014 4 commits
  13. 16 Apr, 2014 2 commits
  14. 15 Apr, 2014 2 commits
  15. 14 Apr, 2014 14 commits