- 15 Jul, 2020 2 commits
- 14 Jul, 2020 1 commit
-
-
Oran Agra authored
in case the rdb child failed, crashed or terminated unexpectedly redis would have marked the replica clients with repl_put_online_on_ack and then kill them only after a minute when no ack was received. it would not stream anything to these connections, so the only effect of this bug is a delay of 1 minute in the replicas attempt to re-connect.
-
- 13 Jul, 2020 2 commits
- 11 Jul, 2020 2 commits
-
-
jimgreen2013 authored
* fix description about ZIP_BIG_PREVLEN(the code is ok), it's similar to antirez#4705 * fix description about ziplist entry encoding field (the code is ok), the max length should be 2^32 - 1 when encoding is 5 bytes
-
杨博东 authored
one of the differences (other than consistent code with SORT, GEORADIUS), is that the LFU of the old key is retained.
-
- 10 Jul, 2020 12 commits
-
-
马永泽 authored
Co-authored-by: Oran Agra <oran@redislabs.com> (styling)
-
Yossi Gottlieb authored
* TLS: Session caching configuration support. * TLS: Remove redundant config initialization.
-
Yossi Gottlieb authored
-
James Hilliard authored
-
Yossi Gottlieb authored
* Tests: fix and reintroduce redis-cli tests. These tests have been broken and disabled for 10 years now! * TLS: add remaining redis-cli support. This adds support for the redis-cli --pipe, --rdb and --replica options previously unsupported in --tls mode. * Fix writeConn().
-
Oran Agra authored
-
Oran Agra authored
-
Oran Agra authored
Similarly to EXPIREAT with TTL in the past, which implicitly deletes the key and return success, RESTORE should not store key that are already expired into the db. When used together with REPLACE it should emit a DEL to keyspace notification and replication stream.
-
huangzhw authored
it to calculate hash, we should use newsds.
-
Oran Agra authored
* tests/valgrind: don't use debug restart DEBUG REATART causes two issues: 1. it uses execve which replaces the original process and valgrind doesn't have a chance to check for errors, so leaks go unreported. 2. valgrind report invalid calls to close() which we're unable to resolve. So now the tests use restart_server mechanism in the tests, that terminates the old server and starts a new one, new PID, but same stdout, stderr. since the stderr can contain two or more valgrind report, it is not enough to just check for the absence of leaks, we also need to check for some known errors, we do both, and fail if we either find an error, or can't find a report saying there are no leaks. other changes: - when killing a server that was already terminated we check for leaks too. - adding DEBUG LEAK which was used to test it. - adding --trace-children to valgrind, although no longer needed. - since the stdout contains two or more runs, we need slightly different way of checking if the new process is up (explicitly looking for the new PID) - move the code that handles --wait-server to happen earlier (before watching the startup message in the log), and serve the restarted server too. * squashme - CR fixes
-
Oran Agra authored
-
zhaozhao.zz authored
For example: BITOP not targetkey sourcekey If targetkey and sourcekey doesn't exist, BITOP has no effect, we do not propagate it, thus can save aof and replica flow.
-
- 25 Jun, 2020 1 commit
-
-
antirez authored
-
- 24 Jun, 2020 1 commit
-
-
antirez authored
-
- 23 Jun, 2020 1 commit
-
-
Oran Agra authored
In order to support the use of multi-exec in pipeline, it is important that MULTI and EXEC are never rejected and it is easy for the client to know if the connection is still in multi state. It was easy to make sure MULTI and DISCARD never fail (done by previous commits) since these only change the client state and don't do any actual change in the server, but EXEC is a different story. Since in the past, it was possible for clients to handle some EXEC errors and retry the EXEC, we now can't affort to return any error on EXEC other than EXECABORT, which now carries with it the real reason for the abort too. Other fixes in this commit: - Some checks that where performed at the time of queuing need to be re- validated when EXEC runs, for instance if the transaction contains writes commands, it needs to be aborted. there was one check that was already done in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF, -NOREPLICAS, -MASTERDOWN - When a command is rejected by processCommand it was rejected with addReply, which was not recognized as an error in case the bad command came from the master. this will enable to count or MONITOR these errors in the future. - make it easier for tests to create additional (non deferred) clients. - add tests for the fixes of this commit.
-
- 22 Jun, 2020 4 commits
- 18 Jun, 2020 1 commit
-
-
chenhui0212 authored
-
- 17 Jun, 2020 1 commit
-
-
Tomasz Poradowski authored
- enforcing of SHUTDOWN_NOSAVE flag in one place to make it consitent when running in Sentinel mode
-
- 16 Jun, 2020 3 commits
-
-
chenhui0212 authored
-
antirez authored
See #7401.
-
antirez authored
Related to #7387.
-
- 15 Jun, 2020 1 commit
-
-
root authored
-
- 14 Jun, 2020 1 commit
-
-
meir@redislabs.com authored
The scan key module API provides the scan callback with the current field name and value (if it exists). Those arguments are RedisModuleString* which means it supposes to point to robj which is encoded as a string. Using createStringObjectFromLongLong function might return robj that points to an integer and so break a module that tries for example to use RedisModule_StringPtrLen on the given field/value. The PR introduces a fix that uses the createObject function and sdsfromlonglong function. Using those function promise that the field and value pass to the to the scan callback will be Strings. The PR also changes the Scan test module to use RedisModule_StringPtrLen to catch the issue. without this, the issue is hidden because RedisModule_ReplyWithString knows to handle integer encoding of the given robj (RedisModuleString). The PR also introduces a new test to verify the issue is solved.
-
- 12 Jun, 2020 2 commits
- 11 Jun, 2020 3 commits
- 10 Jun, 2020 2 commits
-
-
antirez authored
-
Paul Spooren authored
The `LRANK` command returns the index (position) of a given element within a list. Using the `direction` argument it is possible to specify going from head to tail (acending, 1) or from tail to head (decending, -1). Only the first found index is returend. The complexity is O(N). When using lists as a queue it can be of interest at what position a given element is, for instance to monitor a job processing through a work queue. This came up within the Python `rq` project which is based on Redis[0]. [0]: https://github.com/rq/rq/issues/1197 Signed-off-by:
Paul Spooren <mail@aparcar.org>
-