1. 17 Jul, 2019 1 commit
  2. 08 Jul, 2019 2 commits
    • Oran Agra's avatar
      diskless replication on slave side (don't store rdb to file), plus some other related fixes · 2de544cf
      Oran Agra authored
      The implementation of the diskless replication was currently diskless only on the master side.
      The slave side was still storing the received rdb file to the disk before loading it back in and parsing it.
      
      This commit adds two modes to load rdb directly from socket:
      1) when-empty
      2) using "swapdb"
      the third mode of using diskless slave by flushdb is risky and currently not included.
      
      other changes:
      --------------
      distinguish between aof configuration and state so that we can re-enable aof only when sync eventually
      succeeds (and not when exiting from readSyncBulkPayload after a failed attempt)
      also a CONFIG GET and INFO during rdb loading would have lied
      
      When loading rdb from the network, don't kill the server on short read (that can be a network error)
      
      Fix rdb check when performed on preamble AOF
      
      tests:
      run replication tests for diskless slave too
      make replication test a bit more aggressive
      Add test for diskless load swapdb
      2de544cf
    • Angus Pearson's avatar
  3. 03 Jul, 2019 1 commit
  4. 10 Jun, 2019 1 commit
  5. 22 May, 2019 1 commit
    • Angus Pearson's avatar
      Implement `SCAN cursor [TYPE type]` modifier suggested in issue #6107. · bf963253
      Angus Pearson authored
      Add tests to check basic functionality of this optional keyword, and also tested with
      a module (redisgraph). Checked quickly with valgrind, no issues.
      
      Copies name the type name canonicalisation code from `typeCommand`, perhaps this would
      be better factored out to prevent the two diverging and both needing to be edited to
      add new `OBJ_*` types, but this is a little fiddly with C strings.
      
      The [redis-doc](https://github.com/antirez/redis-doc/blob/master/commands.json) repo
      will need to be updated with this new arg if accepted.
      
      A quirk to be aware of here is that the GEO commands are backed by zsets not their own
      type, so they're not distinguishable from other zsets.
      
      Additionally, for sparse types this has the same behaviour as `MATCH` in that it may
      return many empty results before giving something, even for large `COUNT`s.
      bf963253
  6. 21 Mar, 2019 2 commits
  7. 19 Mar, 2019 1 commit
  8. 19 Feb, 2019 1 commit
  9. 21 Jan, 2019 3 commits
  10. 09 Jan, 2019 2 commits
  11. 31 Dec, 2018 1 commit
  12. 06 Dec, 2018 1 commit
  13. 24 Oct, 2018 1 commit
  14. 20 Oct, 2018 1 commit
  15. 19 Oct, 2018 2 commits
  16. 31 Jul, 2018 1 commit
  17. 25 Jul, 2018 3 commits
  18. 03 Jul, 2018 1 commit
  19. 28 Jun, 2018 1 commit
  20. 21 Jun, 2018 1 commit
  21. 18 Jun, 2018 2 commits
    • antirez's avatar
      Streams: fix xreadGetKeys() for correctness. · 20766608
      antirez authored
      The old version could not handle the fact that "STREAMS" is a valid key
      name for streams. Now we really try to parse the command like the
      command implementation would do.
      
      Related to #5028 and 4857.
      20766608
    • antirez's avatar
      Streams: fix xreadGetKeys() buffer overflow. · a0b27dae
      antirez authored
      The loop allocated a buffer for the right number of keys positions, then
      overflowed it going past the limit.
      
      Related to #4857 and cause of the memory violation seen in #5028.
      a0b27dae
  22. 14 Jun, 2018 1 commit
  23. 13 Jun, 2018 1 commit
  24. 12 Jun, 2018 1 commit
  25. 04 Jun, 2018 1 commit
  26. 29 Apr, 2018 1 commit
  27. 27 Feb, 2018 2 commits
  28. 11 Feb, 2018 1 commit
  29. 12 Jan, 2018 1 commit
    • antirez's avatar
      Fix getKeysUsingCommandTable() in the case of nagative arity. · 2f8476df
      antirez authored
      This fixes a crash with Redis Cluster when OBJECT is mis-used, because
      getKeysUsingCommandTable() will call serverPanic() detecting we are
      accessing an invalid argument in the case "OBJECT foo" is called.
      
      This bug was introduced when OBJECT HELP was introduced, because the key
      argument is set fixed at index 2 in the command table, however now
      OBJECT may be called with an insufficient number of arguments to extract
      the key.
      
      The "Right Thing" would be to have a specific function to extract keys
      from the OBJECT command, however this is kinda of an overkill, so I
      preferred to make getKeysUsingCommandTable() more robust and just return
      no keys when it's not possible to honor the command table, because new
      commands are often added and also there are a number with an HELP
      subcommand violating the normal form, and crashing for this trivial
      reason or having many command-specific key extraction functions is not
      great.
      2f8476df
  30. 01 Dec, 2017 1 commit