- 17 Jul, 2019 1 commit
-
-
zhaozhao.zz authored
-
- 08 Jul, 2019 2 commits
-
-
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
-
Angus Pearson authored
-
- 03 Jul, 2019 1 commit
-
-
antirez authored
-
- 10 Jun, 2019 1 commit
-
-
Angus Pearson authored
and to keep OBJ_* enum to string canonicalization in one place.
-
- 22 May, 2019 1 commit
-
-
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.
-
- 21 Mar, 2019 2 commits
- 19 Mar, 2019 1 commit
-
-
Dvir Volk authored
-
- 19 Feb, 2019 1 commit
-
-
antirez authored
-
- 21 Jan, 2019 3 commits
- 09 Jan, 2019 2 commits
- 31 Dec, 2018 1 commit
-
-
Bruce Merry authored
This prevents an integer overflow bug. Closes #5737.
-
- 06 Dec, 2018 1 commit
-
-
lsytj0413 authored
-
- 24 Oct, 2018 1 commit
-
-
antirez authored
-
- 20 Oct, 2018 1 commit
-
-
hujie authored
-
- 19 Oct, 2018 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
-
- 31 Jul, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 25 Jul, 2018 3 commits
-
-
antirez authored
Related to #4852.
-
antirez authored
-
zhaozhao.zz authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 28 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 21 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 18 Jun, 2018 2 commits
-
-
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.
-
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.
-
- 14 Jun, 2018 1 commit
-
-
antirez authored
Thanks to @kevinmcgehee for signaling the issue and reasoning about the consequences and potential fixes. Issue #5015.
-
- 13 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 12 Jun, 2018 1 commit
-
-
antirez authored
Since the introduction of ZPOP makes this needed. Thanks to @oranagra for reporting.
-
- 04 Jun, 2018 1 commit
-
-
赵磊 authored
-
- 29 Apr, 2018 1 commit
-
-
Itamar Haber authored
An implementation of the [Ze POP Redis Module](https://github.com/itamarhaber/zpop) as core Redis commands. Fixes #1861.
-
- 27 Feb, 2018 2 commits
- 11 Feb, 2018 1 commit
-
-
赵磊 authored
-
- 12 Jan, 2018 1 commit
-
-
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.
-
- 01 Dec, 2017 1 commit
-
-
antirez authored
-