1. 02 Jul, 2018 1 commit
  2. 01 Jul, 2018 1 commit
  3. 30 Jun, 2018 1 commit
  4. 27 Jun, 2018 2 commits
  5. 26 Jun, 2018 2 commits
  6. 21 Jun, 2018 1 commit
  7. 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
  8. 19 Jun, 2018 1 commit
  9. 14 Jun, 2018 1 commit
  10. 12 Jun, 2018 1 commit
  11. 11 Jun, 2018 2 commits
  12. 05 Jun, 2018 1 commit
  13. 25 May, 2018 1 commit
  14. 24 May, 2018 1 commit
  15. 17 May, 2018 1 commit
    • Oran Agra's avatar
      Active defrag fixes for 32bit builds · ad133e10
      Oran Agra authored
      problems fixed:
      * failing to read fragmentation information from jemalloc
      * overflow in jemalloc fragmentation hint to the defragger
      * test suite not triggering eviction after population
      ad133e10
  16. 15 May, 2018 2 commits
  17. 11 May, 2018 2 commits
  18. 29 Apr, 2018 1 commit
  19. 23 Apr, 2018 1 commit
  20. 20 Apr, 2018 1 commit
  21. 25 Mar, 2018 1 commit
  22. 15 Mar, 2018 6 commits
  23. 14 Mar, 2018 1 commit
  24. 12 Mar, 2018 1 commit
    • Oran Agra's avatar
      Adding real allocator fragmentation to INFO and MEMORY command + active defrag test · 806736cd
      Oran Agra authored
      other fixes / improvements:
      - LUA script memory isn't taken from zmalloc (taken from libc malloc)
        so it can cause high fragmentation ratio to be displayed (which is false)
      - there was a problem with "fragmentation" info being calculated from
        RSS and used_memory sampled at different times (now sampling them together)
      
      other details:
      - adding a few more allocator info fields to INFO and MEMORY commands
      - improve defrag test to measure defrag latency of big keys
      - increasing the accuracy of the defrag test (by looking at real grag info)
        this way we can use an even lower threshold and still avoid false positives
      - keep the old (total) "fragmentation" field unchanged, but add new ones for spcific things
      - add these the MEMORY DOCTOR command
      - deduct LUA memory from the rss in case of non jemalloc allocator (one for which we don't "allocator active/used")
      - reduce sampling rate of the rss and allocator info
      806736cd
  25. 24 Jan, 2018 1 commit
  26. 09 Jan, 2018 1 commit
  27. 04 Dec, 2017 1 commit
  28. 01 Dec, 2017 3 commits
    • antirez's avatar
      Streams: add some initial test for XREVRANGE. · 45fe1f5e
      antirez authored
      45fe1f5e
    • antirez's avatar
      Streams: fix XREAD test broken after previous tests improvements. · 1898c505
      antirez authored
      10% of times the data is not just "item 0" but there is also the
      "otherfield" part. Use [lrange] to avoid the issue.
      This commit fixes #4416.
      1898c505
    • antirez's avatar
      Streams: move ID ms/seq separator from '.' to '-' · 5082ec64
      antirez authored
      After checking with the community via Twitter (here:
      https://twitter.com/antirez/status/915130876861788161) the verdict was to
      use ":". However I later realized, after users lamented the fact that
      it's hard to copy IDs just with double click, that this was the reason
      why I moved to "." in the first instance. Fortunately "-", that was the
      other option with most votes, also gets selected with double click on
      most terminal applications on Linux and MacOS.
      
      So my reasoning was:
      
      1) We can't retain "." because it's actually confusing to newcomers, it
      looks like a floating number, people may be tricked into thinking they
      can order IDs numerically as floats.
      
      2) Moving to a double-click-to-select format is much better. People will
      work with such IDs for long time when coding / debugging. Why making now
      a choice that will impact this for the next years?
      
      The only other viable option was "-", and that's what I did. Thanks.
      5082ec64