merge latest redis source code#2
Merged
t00350320 merged 326 commits intot00350320:unstablefrom Nov 23, 2020
Merged
Conversation
[Redis-benchmark] Support zset type
Fix typos in README.md
Adds --pattern option to cli's --bigkeys, --hotkeys & --scan modes
Obsoletes the need to run `make` before `make test`.
* Replace usage of wrongtypeerr with helper
and a misspell in rax.c
…1690) Add Linux kernel OOM killer control option. This adds the ability to control the Linux OOM killer oom_score_adj parameter for all Redis processes, depending on the process role (i.e. master, replica, background child). A oom-score-adj global boolean flag control this feature. In addition, specific values can be configured using oom-score-adj-values if additional tuning is required.
Client that issued WAIT last will most likely have the highest replication offset, so imagine a probably common case where all clients are waiting for the same number of replicas. we prefer the loop to start from the last client (one waiting for the highest offset), so that the optimization in the function will call replicationCountAcksByOffset for each client until it found a good one, and stop calling it for the rest of the clients. the way the loop was implemented would mean that in such case it is likely to call replicationCountAcksByOffset for all clients. Note: the change from > to >= is not directly related to the above. Co-authored-by: 曹正斌 <[email protected]>
…on (#6900) In order to keep the redismodule.h self-contained but still usable with gcc v10 and later, annotate each API function tentative definition with the __common__ attribute. This avoids the 'multiple definition' errors modules will otherwise see for all API functions at link time. Further details at gcc.gnu.org/gcc-10/porting_to.html Turn the existing __attribute__ ((unused)), ((__common__)) and ((print)) annotations into conditional macros for any compilers not accepting this syntax. These macros only expand to API annotations under gcc. Provide a pre- and post- macro for every API function, so that they can be defined differently by the file that includes redismodule.h. Removing REDISMODULE_API_FUNC in the interest of keeping the function declarations readable. Co-authored-by: Yossi Gottlieb <[email protected]> Co-authored-by: Oran Agra <[email protected]>
00272d669 Rename sds calls so they don't conflict in Redis. git-subtree-dir: deps/hiredis git-subtree-split: 00272d669b11e96b8311d9bfe167c117f8887dd6
…unique-sds-symbols
This resolves an issue with sentinel that was created when hiredis was recently updated. this was due to sds symbol names clashing, since hiredis now includes different implementation of sdsrange than the one in redis. The state of things is that redis-benchamrk and redis-cli include only hiredis sds implementation. redis-cli even operates (calls sdscatlen) on sds that's allocated by hiredis. Sentinel however has both implementations of the sds library in it (now each with it's own unique symbols).
Avoid re-configuring (and validating) SSL/TLS configuration on `CONFIG SET` when TLS is not actively enabled for incoming connections, cluster bus or replication. This fixes failures when tests run without `--tls` on binaries that were built with TLS support. An additional benefit is that it's now possible to perform a multi-step configuration process while TLS is disabled. The new configuration will be verified and applied only when TLS is effectively enabled.
The `REDISMODULE_CLIENTINFO_FLAG_SSL` flag was already a part of the `RedisModuleClientInfo` structure but was not implemented.
65a3307 added rejectCommand which takes an robj reply and passes it through addReplyErrorSafe to addReplyErrorLength. The robj contains newline at it's end, but addReplyErrorSafe converts it to spaces, and passes it to addReplyErrorLength which adds the protocol newlines. The result was that most error replies (like OOM) had extra two trailing spaces in them.
It was already defined in the API header and the documentation, but not used by the implementation.
Edit auth failed message include user disabled case in hello command
Since users often post just the crash log in github issues, the log print that's above it is missing. No reason not to include the size in the panic message itself.
Correcting the variable to clusterMsgModule.
…7674) After fork, the child process(redis-aof-rewrite) will get the fd opened by the parent process(redis), when redis killed by kill -9, it will not graceful exit(call prepareForShutdown()), so redis-aof-rewrite thread may still alive, the fd(lock) will still be held by redis-aof-rewrite thread, and redis restart will fail to get lock, means fail to start. This issue was causing failures in the cluster tests in github actions. Co-authored-by: Oran Agra <[email protected]>
We wanna avoid a chance of someone using the pointer in it after it'll be freed / realloced.
It was also using the wrong struct, but luckily RedisModuleFlushInfo and RedisModuleLoadingProgress are identical.
use 40 zeros rather than 30 zeros to match CONFIG_RUN_ID_SIZE. this doesn't have any real implications.
…odules (#8037) The RMAPI_FUNC_SUPPORTED was defined in the wrong place on redismodule.h and was not visible to modules.
Test support for the new map, null and push message types. Map objects are parsed as a list of lists of key value pairs.
for instance: user => john password => 123
will be parsed to the following TCL list:
{{user john} {password 123}}
Also added the following tests:
Redirection still works with RESP3
Able to use a RESP3 client as a redirection client
No duplicate invalidation messages when turning BCAST mode on after normal tracking
Server is able to evacuate enough keys when num of keys surpasses limit by more than defined initial effort
Different clients using different protocols can track the same key
OPTOUT tests
OPTIN tests
Clients can redirect to the same connection
tracking-redir-broken test
HELLO 3 checks
Invalidation messages still work when using RESP3, with and without redirection
Switching to RESP3 doesn't disturb previous tracked keys
Tracking info is correct
Flushall and flushdb produce invalidation messages
These tests achieve 100% line coverage for tracking.c using lcov.
* Rewritten commands are logged as their original command Co-authored-by: Madelyn Olson <[email protected]>
(this is a fixup for #8006) Co-authored-by: Madelyn Olson <[email protected]>
BLPOP when there are elements in the list works in the same way as LPOP does. Due to this they also does the same repetitive action and logic for the same is written at two different places. This is a bad code practice as the one needs the context to change the BLPOP list pop code as well when the LPOP code gets changed. Separated the generic logic from LPOP to a function that is being used by the BLPOP code as well.
* Fix build warning in hellohook,c and testmodule.c * Change ci->id type to (unsigned long long)
- Add ZDIFF and ZDIFFSTORE which work similarly to SDIFF and SDIFFSTORE - Make sure the new WITHSCORES argument that was added for ZUNION isn't considered valid for ZUNIONSTORE Co-authored-by: Oran Agra <[email protected]>
Add two optional callbacks to the RedisModuleTypeMethods structure, which is `free_effort` and `unlink`. the `free_effort` callback indicates the effort required to free a module memory. Currently, if the effort exceeds LAZYFREE_THRESHOLD, the module memory may be released asynchronously. the `unlink` callback indicates the key has been removed from the DB by redis, and may soon be freed by a background thread. Add `lazyfreed_objects` info field, which represents the number of objects that have been lazyfreed since redis was started. Add `RM_GetTypeMethodVersion` API, which return the current redis-server runtime value of `REDISMODULE_TYPE_METHOD_VERSION`. You can use that when calling `RM_CreateDataType` to know which fields of RedisModuleTypeMethods are gonna be supported and which will be ignored.
Syntax: COPY <key> <new-key> [DB <dest-db>] [REPLACE] No support for module keys yet. Co-authored-by: tmgauss Co-authored-by: Itamar Haber <[email protected]> Co-authored-by: Oran Agra <[email protected]>
* Configuration file default should now be "auto". * Expose "process_supervised" as an info field. * Log messages improvements (clarify required systemd config, report auto-detected supervision mode, etc.) * Set server.supervised properly, so it can take precedence of "daemonize" configuration. * Produce clear warning if systemd is detected/requested but executable is compiled without support for it, instead of silently ignoring. * Handle systemd notification error on startup, and turn off supervised mode if it failed.
ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count] When the offset is too large, the query is very slow. Especially when the offset is greater than the length of zset it is easy to determine whether the offset is greater than the length of zset at first, and If it exceed the length of zset, then return directly. Co-authored-by: Oran Agra <[email protected]>
) Blocking command should not be used with MULTI, LUA, and RM_Call. This is because, the caller, who executes the command in this context, expects a reply. Today, LUA and MULTI have a special (and different) treatment to blocking commands: LUA - Most commands are marked with no-script flag which are checked when executing and command from LUA, commands that are not marked (like XREAD) verify that their blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag). MULTI - Command that is going to block, first verify that the client is not inside multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they return a result which is a match to the empty key with no timeout (for example blpop inside MULTI will act as lpop) For modules that perform RM_Call with blocking command, the returned results type is REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened. Disadvantages of the current state are: No unified approach, LUA, MULTI, and RM_Call, each has a different treatment Module can not safely execute blocking command (and get reply or error). Though It is true that modules are not like LUA or MULTI and should be smarter not to execute blocking commands on RM_Call, sometimes you want to execute a command base on client input (for example if you create a module that provides a new scripting language like javascript or python). While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to check if the command came from another module using RM_Call. So there is no way for a module to know not to block another module RM_Call execution. This commit adds a way to unify the treatment for blocking clients by introducing a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag turned on to signify that the client should not be blocked. A blocking command verifies that the flag is turned off before blocking. If a blocking command sees that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results which are matches to empty key with no timeout (as MULTI does today). The new flag is checked on the following commands: List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, Zset blocking commands: BZPOPMIN, BZPOPMAX Stream blocking commands: XREAD, XREADGROUP SUBSCRIBE, PSUBSCRIBE, MONITOR In addition, the new flag is turned on inside the AOF client, we do not want to block the AOF client to prevent deadlocks and commands ordering issues (and there is also an existing assert in the code that verifies it). To keep backward compatibility on LUA, all the no-script flags on existing commands were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept. To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE). We added a special treatment on those commands to allow executing them on MULTI. The only backward compatibility issue that this PR introduces is that now MONITOR is not allowed inside MULTI. Tests were added to verify blocking commands are not blocking the client on LUA, MULTI, or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag. Co-authored-by: Oran Agra <[email protected]> Co-authored-by: Itamar Haber <[email protected]>
… replica (#8016) The bug was introduced by #5021 which only attempted avoid EXIST on an already expired key from returning 1 on a replica. Before that commit, dbExists was used instead of lookupKeyRead (which had an undesired effect to "touch" the LRU/LFU) Other than that, this commit fixes OBJECT to also come empty handed on expired keys in replica. And DEBUG DIGEST-VALUE to behave like DEBUG OBJECT (get the data from the key regardless of it's expired state)
backtrace can be compile time disabled.
…fig file (#8046) Fix: When oom-score-adj-values is provided in the config file after oom-score-adj yes, it'll take an immediate action, before readOOMScoreAdj was acquired, resulting in an error (out of range score due to uninitialized value. delay the reaction the real call is made by main(). Since the values are clamped to -1000..1000, and they're applied as an offset from the value at startup (which may be -1000), we need to allow the offsets to reach to +2000 so that a value of +1000 is achievable in case the value at startup was -1000. Adding an option for absolute values rather than relative ones.
This is hopefully usually harmles. The server.ready_keys will usually be empty so the code after releasing the GIL will soon be done. The only case where it'll actually process things is when a module releases a client (or module) blocked on a key, by triggering this NOT from within a command (e.g. a timer event). This bug was introduced in redis 6.0.9, see #7903
If we enable diskless replication, set repl-diskless-sync-delay to 0, and master has non-rdb child process such as rewrite aof child, master will try to start to a new BGSAVE but fails immediately (before fork) when replicas ask for full synchronization, and master always fails to start a new BGSAVE and disconnects with replicas until non-rdb child process exists. this bug was introduced in #6271 (not yet released in 6.0.x)
When USE_SYSTEMD=yes is specified, try to use pkg-config to determine libsystemd linker flags. If not found, silently fall back to simply using "-lsystemd". We now use a LIBSYSTEMD_LIBS variable so users can explicitly override it and specify their own library. If USE_SYSTEMD is unspecified the old behavior of auto-enabling it if both pkg-config and libsystemd are available is retained.
Co-authored-by: Oran Agra <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.