- 24 Jun, 2020 2 commits
- 23 Jun, 2020 2 commits
-
-
Salvatore Sanfilippo authored
EXEC always fails with EXECABORT and multi-state is cleared
-
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 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
Salvatore Sanfilippo authored
fix memory leak in sentinel connection sharing
-
hwware authored
-
- 18 Jun, 2020 3 commits
-
-
Salvatore Sanfilippo authored
Fix comments in listpack.c
-
chenhui0212 authored
-
Salvatore Sanfilippo authored
Inconsistent RDB saving when in Sentinel mode
-
- 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 4 commits
-
-
chenhui0212 authored
-
antirez authored
See #7401.
-
antirez authored
-
antirez authored
Related to #7387.
-
- 15 Jun, 2020 1 commit
-
-
Salvatore Sanfilippo authored
Fix RM_ScanKey module api not to return int encoded strings
-
- 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 3 commits
-
-
antirez authored
-
Salvatore Sanfilippo authored
Fix Server Crash in LCS Command
-
antirez authored
-
- 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>
-
- 09 Jun, 2020 3 commits
- 08 Jun, 2020 9 commits
-
-
Salvatore Sanfilippo authored
return the correct proto version
-
Salvatore Sanfilippo authored
Don't queue commands in an already aborted MULTI state
-
Salvatore Sanfilippo authored
Avoid rejecting WATCH / UNWATCH, like MULTI/EXEC/DISCARD
-
Salvatore Sanfilippo authored
AOF: append origin SET if no expire option
-
Salvatore Sanfilippo authored
fix disconnectSlaves, to try to free each slave.
-
Salvatore Sanfilippo authored
donot free protected client in freeClientsInAsyncFreeQueue()
-
Oran Agra authored
the recent change in that loop (iteration rather than waiting for it to be empty) was intended to avoid an endless loop in case some slave would refuse to be freed. but the lookup of the first client remained, which would have caused it to try the first one again and again instead of moving on.
-
Oran Agra authored
-
Oran Agra authored
Much like MULTI/EXEC/DISCARD, the WATCH and UNWATCH are not actually operating on the database or server state, but instead operate on the client state. the client may send them all in one long pipeline and check all the responses only at the end, so failing them may lead to a mismatch between the client state on the server and the one on the client end, and execute the wrong commands (ones that were meant to be discarded) the watched keys are not actually stored in the client struct, but they are in fact part of the client state. for instance, they're not cleared or moved in SWAPDB or FLUSHDB.
-
- 07 Jun, 2020 1 commit
-
-
xhe authored
HELLO should return the current proto version, while the code hardcoded 3
-