mirror of https://mirror.osredm.com/root/redis.git
15706f2e82
# Problem Some redis modules need to call `CONFIG GET/SET` commands. Server may be ran with `rename-command CONFIG ""`(or something similar) which leads to the module being unable to access the config. # Solution Added new API functions for use by modules ``` RedisModuleConfigIterator* RedisModule_GetConfigIterator(RedisModuleCtx *ctx, const char *pattern); void RedisModule_ReleaseConfigIterator(RedisModuleCtx *ctx, RedisModuleConfigIterator *iter); const char *RedisModule_ConfigIteratorNext(RedisModuleConfigIterator *iter); int RedisModule_GetConfigType(const char *name, RedisModuleConfigType *res); int RedisModule_GetBoolConfig(RedisModuleCtx *ctx, const char *name, int *res); int RedisModule_GetConfig(RedisModuleCtx *ctx, const char *name, RedisModuleString **res); int RedisModule_GetEnumConfig(RedisModuleCtx *ctx, const char *name, RedisModuleString **res); int RedisModule_GetNumericConfig(RedisModuleCtx *ctx, const char *name, long long *res); int RedisModule_SetBoolConfig(RedisModuleCtx *ctx, const char *name, int value, RedisModuleString **err); int RedisModule_SetConfig(RedisModuleCtx *ctx, const char *name, RedisModuleString *value, RedisModuleString **err); int RedisModule_SetEnumConfig(RedisModuleCtx *ctx, const char *name, RedisModuleString *value, RedisModuleString **err); int RedisModule_SetNumericConfig(RedisModuleCtx *ctx, const char *name, long long value, RedisModuleString **err); ``` ## Implementation The work is mostly done inside `config.c` as I didn't want to expose the config dict outside of it. That means each of these module functions has a corresponding method in `config.c` that actually does the job. F.e `RedisModule_SetEnumConfig` calls `moduleSetEnumConfig` which is implemented in `config.c` ## Notes Also, refactored `configSetCommand` and `restoreBackupConfig` functions for the following reasons: - code and logic is now way more clear in `configSetCommand`. Only caveat here is removal of an optimization that skipped running apply functions that already have ran in favour of code clarity. - Both functions needlessly separated logic for module configs and normal configs whereas no such separation is needed. This also had the side effect of removing some allocations. - `restoreBackupConfig` now has clearer interface and can be reused with ease. One of the places I reused it is for the individual `moduleSet*Config` functions, each of which needs the restoration functionality but for a single config only. ## Future Additionally, a couple considerations were made for potentially extending the API in the future - if need be an API for atomically setting multiple config values can be added - `RedisModule_SetConfigsTranscationStart/End` or similar that can be put around `RedisModule_Set*Config` calls. - if performance is an issue an API `RedisModule_GetConfigIteratorNextWithTypehint` or similar may be added in order not to incur the additional cost of calling `RedisModule_GetConfigType`. --------- Co-authored-by: Oran Agra <oran@redislabs.com> |
||
|---|---|---|
| .. | ||
| assets | ||
| cluster | ||
| helpers | ||
| integration | ||
| modules | ||
| sentinel | ||
| support | ||
| tmp | ||
| unit | ||
| README.md | ||
| instances.tcl | ||
| test_helper.tcl | ||
README.md
Redis Test Suite
The normal execution mode of the test suite involves starting and manipulating
local redis-server instances, inspecting process state, log files, etc.
The test suite also supports execution against an external server, which is
enabled using the --host and --port parameters. When executing against an
external server, tests tagged external:skip are skipped.
There are additional runtime options that can further adjust the test suite to match different external server configurations:
| Option | Impact |
|---|---|
--singledb |
Only use database 0, don't assume others are supported. |
--ignore-encoding |
Skip all checks for specific encoding. |
--ignore-digest |
Skip key value digest validations. |
--cluster-mode |
Run in strict Redis Cluster compatibility mode. |
--large-memory |
Enables tests that consume more than 100mb |
Tags
Tags are applied to tests to classify them according to the subsystem they test, but also to indicate compatibility with different run modes and required capabilities.
Tags can be applied in different context levels:
start_servercontexttagscontext that bundles several tests together- A single test context.
The following compatibility and capability tags are currently used:
| Tag | Indicates |
|---|---|
external:skip |
Not compatible with external servers. |
cluster:skip |
Not compatible with --cluster-mode. |
large-memory |
Test that requires more than 100mb |
tls:skip |
Not compatible with --tls. |
tsan:skip |
Not compatible with running under thread sanitizer. |
needs:repl |
Uses replication and needs to be able to SYNC from server. |
needs:debug |
Uses the DEBUG command or other debugging focused commands (like OBJECT REFCOUNT). |
needs:pfdebug |
Uses the PFDEBUG command. |
needs:config-maxmemory |
Uses CONFIG SET to manipulate memory limit, eviction policies, etc. |
needs:config-resetstat |
Uses CONFIG RESETSTAT to reset statistics. |
needs:reset |
Uses RESET to reset client connections. |
needs:save |
Uses SAVE or BGSAVE to create an RDB file. |
When using an external server (--host and --port), filtering using the
external:skip tags is done automatically.
When using --cluster-mode, filtering using the cluster:skip tag is done
automatically.
When not using --large-memory, filtering using the largemem:skip tag is done
automatically.
In addition, it is possible to specify additional configuration. For example, to
run tests on a server that does not permit SYNC use:
./runtest --host <host> --port <port> --tags -needs:repl