- 24 Mar, 2021 5 commits
-
-
Oran Agra authored
the corrupt-dump-fuzzer test found a case where an access to a corrupt stream would have caused accessing to uninitialized memory. now it'll panic instead. The issue was that there was a stream that says it has more than 0 records, but looking for the max ID came back empty handed. p.s. when sanitize-dump-payload is used, this corruption is detected, and the RESTORE command is gracefully rejected.
-
Itamar Haber authored
-
chenyangyang authored
Add a check to ensure that the expire parameters in RM_SetExpire and RM_SetAbsExpire must be positive.
-
Oran Agra authored
We sometimes see the crash report saying we were killed by a random process even in cases where the crash was spontanius in redis. for instance, crashes found by the corrupt-dump test. It looks like this si_pid is sometimes left uninitialized, and a good way to tell if the crash originated in redis or trigged by outside is to look at si_code, real signal codes are always > 0, and ones generated by kill are have si_code of 0 or below.
-
yoav-steinberg authored
-
- 23 Mar, 2021 2 commits
- 22 Mar, 2021 7 commits
-
-
Wen Hui authored
-
Huang Zhw authored
sentinelGetInstanceTypeString is the same as sentinelRedisInstanceTypeStr, and not referenced by any functions.
-
Yossi Gottlieb authored
-
Yossi Gottlieb authored
Reading CoW from /proc/<pid>/smaps can be slow with large processes on some platforms. This measures the time it takes to read CoW info and limits the duty cycle of future updates to roughly 1/100. As current_cow_size no longer represnets a current, fixed interval value there is also a new current_cow_size_age field that provides information about the age of the size value, in seconds.
-
Oran Agra authored
-
Oran Agra authored
Since redis 6.2, redis immediately tries to connect to the master, not waiting for replication cron. in the slow freebsd CI, this test failed and master_link_status was already "up" when INFO was called.
-
Huang Zhw authored
redis_check_rdb in some scenarios only stopLoading is called because startLoadingFile is called too late.
-
- 17 Mar, 2021 4 commits
-
-
Meir Shpilraien (Spielrein) authored
pcall function runs another LUA function in protected mode, this means that any error will be caught by this function and will not stop the LUA execution. The script kill mechanism uses error to stop the running script. Scripts that uses pcall can catch the error raise by the script kill mechanism, this will cause a script like this to be unkillable: local f = function() while 1 do redis.call('ping') end end while 1 do pcall(f) end The fix is, when we want to kill the script, we set the hook function to be invoked after each line. This will promise that the execution will get another error before it is able to enter the pcall function again.
-
Theo Buehler authored
Some operating systems (e.g., NetBSD and OpenBSD) have switched to using a 64-bit integer for time_t on all platforms. This results in currently harmless compiler warnings due to potential truncation. These changes fix these minor portability concerns. * Fix format string for systems with 64 bit time * use llabs to avoid truncation with 64 bit time
-
Wen Hui authored
fix typo
-
Yossi Gottlieb authored
In the long term we may want to move away from anet completely and have everything implemented natively in connection.c, instead of having an extra layer. For now, just get rid of unused code.
-
- 16 Mar, 2021 9 commits
-
-
Huang Zhw authored
In certain scenario start_server may think it failed to start a redis server although it started successfully. in these cases, it'll not terminate it, and it'll remain running when the test is over. In start_server if config doesn't have bind (the minimal.conf in introspection.tcl), it will try to bind ipv4 and ipv6. One may success while other fails. It will output "Could not create server TCP listening socket". wait_server_started uses this message to check whether instance started successfully. So it will consider that it failed even though redis started successfully. Additionally, in some cases it wasn't clear to users why the server exited, since the warning message printed to the log, could in some cases be harmless, and in some cases fatal. This PR adds makes a clear distinction between a warning log message and a fatal one, and changes the test suite to look for the fatal message.
-
Saravjeet 'Aman' Singh authored
prettify
-
Garen Chan authored
-
Ikko Ashimine authored
arguements -> arguments
-
Meir Shpilraien (Spielrein) authored
lookupKeyReadOrReply and lookupKeyWriteOrReply might decide to reply to the user with the given robj reply. This reply might be an error reply and if so addReply function is used instead of addReplyErrorObject which will cause the error reply not to be counted on stats. The fix checks the first char in the reply and if its '-' (error) it uses addReplyErrorObject.
-
Wen Hui authored
-
Oran Agra authored
REDISMODULE_CTX_FLAGS_EVICT and REDISMODULE_CTX_FLAGS_MAXMEMORY shouldn't be set when the module is run inside a replica that doesn't do eviction. one may argue that the database is under eviction (the master does eviction and sends DELs to the replica). but on the other hand, we don't really know the master's configuration. all that matters is if the current instance does evictions or not.
-
Yossi Gottlieb authored
listenToPort attempts to gracefully handle and ignore certain errors but does not store errno prior to logging, which in turn calls several libc functions that may overwrite errno. This has been discovered due to libmusl strftime() always returning with errno set to EINVAL, which resulted with docker-library/redis#273.
-
Madelyn Olson authored
Redact config set requirepass/masterauth/masteruser from slowlog in addition to showing ACL commands without sensitive values.
-
- 15 Mar, 2021 1 commit
-
-
guybe7 authored
1. moduleReplicateMultiIfNeeded should use server.in_eval like moduleHandlePropagationAfterCommandCallback 2. server.in_eval could have been set to 1 and not reset back to 0 (a lot of missed early-exits after in_eval is already 1) Note: The new assertions in processCommand cover (2) and I added two module tests to cover (1) Implications: If an EVAL that failed (and thus left server.in_eval=1) runs before a module command that replicates, the replication stream will contain MULTI (because moduleReplicateMultiIfNeeded used to check server.lua_caller which is NULL at this point) but not EXEC (because server.in_eval==1) This only affects modules as module.c the only user of server.in_eval. Affects versions 6.2.0, 6.2.1
-
- 14 Mar, 2021 2 commits
-
-
Huang Zhw authored
-
Guillem Jover authored
On a replica we do accept connections, even though commands accessing the database will operate in read-only mode. But the server is still already operational and processing commands. Not sending the readiness notification means that on a HA setup where the nodes all start as replicas (with replicaof in the config) with a replica that cannot connect to the master server and which might not come back in a predictable amount of time or at all, the service supervisor will end up timing out the service and terminating it, with no option to promote it to be the main instance. This seems counter to what the readiness notification is supposed to be signaling. Instead send the readiness notification when we start accepting commands, and then send the various server status changes as that. Fixes: commit 641c64ad Fixes: commit dfb598cf
-
- 12 Mar, 2021 1 commit
-
-
KinWaiYuen authored
This commit more efficiently computes the cluster bulk slots response by looping over the entire slot space once, instead of for each node.
-
- 11 Mar, 2021 4 commits
-
-
Wen Hui authored
-
Oran Agra authored
same as DISCARD, this command (RESET) is about client state, not server state
-
Harkrishn Patro authored
Co-authored-by:
Harkrishn Patro <harkrisp@amazon.com>
-
- 10 Mar, 2021 5 commits
-
-
cheese1 authored
-
guybe7 authored
Bug 1: When a module ctx is freed moduleHandlePropagationAfterCommandCallback is called and handles propagation. We want to prevent it from propagating commands that were not replicated by the same context. Example: 1. module1.foo does: RM_Replicate(cmd1); RM_Call(cmd2); RM_Replicate(cmd3) 2. RM_Replicate(cmd1) propagates MULTI and adds cmd1 to also_propagagte 3. RM_Call(cmd2) create a new ctx, calls call() and destroys the ctx. 4. moduleHandlePropagationAfterCommandCallback is called, calling alsoPropagates EXEC (Note: EXEC is still not written to socket), setting server.in_trnsaction = 0 5. RM_Replicate(cmd3) is called, propagagting yet another MULTI (now we have nested MULTI calls, which is no good) and then cmd3 We must prevent RM_Call(cmd2) from resetting server.in_transaction. REDISMODULE_CTX_MULTI_EMITTED was revived for that purpose. Bug 2: Fix issues with nested RM_Call where some have '!' and some don't. Example: 1. module1.foo does RM_Call of module2.bar without replication (i.e. no '!') 2. module2.bar internally calls RM_Call of INCR with '!' 3. at the end of module1.foo we call RM_ReplicateVerbatim We want the replica/AOF to see only module1.foo and not the INCR from module2.bar Introduced a global replication_allowed flag inside RM_Call to determine whether we need to replicate or not (even if '!' was specified) Other changes: Split beforePropagateMultiOrExec to beforePropagateMulti afterPropagateExec just for better readability
-
Itamar Haber authored
Ref: https://github.com/redis/redis-doc/pull/1529
-
guybe7 authored
Have a clear separation between in and out flags Other changes: delete dead code in RM_ZsetIncrby: if zsetAdd returned error (happens only if the result of the operation is NAN or if score is NAN) we return immediately so there is no way that zsetAdd succeeded and returned NAN in the out-flags
-
Oran Agra authored
`master_sync_perc` and `loading_loaded_perc` don't have that sign, and i think the info field should be a raw floating point number (the name suggests its units). we already have `used_memory_peak_perc` and `used_memory_dataset_perc` which do add the `%` sign, but: 1) i think it was a mistake but maybe too late to fix now, and maybe not too late to fix for `current_fork_perc` 2) it is more important to be consistent with the two other "progress" "prec" metrics, and not with the "utilization" metric.
-