- 29 Jul, 2024 1 commit
-
-
YaacovHazan authored
-
- 28 Jul, 2024 2 commits
-
-
YaacovHazan authored
-
Lior Kogan authored
-
- 25 Jul, 2024 2 commits
-
-
Oran Agra authored
* some tests didn't wait for replication offset sync * tests that used deferring client, didn't wait for it to get blocked. an in some cases, the replication offset sync ended before the deferring client finished, so the digest match failed. * some tests used deferring clients excessively * the tests didn't read the client response * the tests didn't close the client (fd leak)
-
Moti Cohen authored
-
- 24 Jul, 2024 1 commit
-
-
Moti Cohen authored
Modify RDB_TYPE_HASH_METADATA layout to store expiration times relative to the minimum expiration time, which is written at the start as absolute time.
-
- 22 Jul, 2024 2 commits
-
-
Oran Agra authored
[exception]: Executing test client: ERR FAILOVER target replica is not online.. ERR FAILOVER target replica is not online. while executing "$node_0 failover to $node_1_host $node_1_port" ("uplevel" body line 16) invoked from within "uplevel 1 $code" (procedure "test" line 58) invoked from within "test {failover command to specific replica works} { [err]: client evicted due to percentage of maxmemory in tests/unit/client-eviction.tcl Expected 33622 >= 220200 && 33622 < 440401 (context: type eval line 17 cmd {assert {$tot_mem >= $n && $tot_mem < $maxmemory_clients_actual}} proc ::test)
-
Oran Agra authored
Recently in #13361, i attempted to fix a race between FLUSHALL and BGSAVE, where despite calling killRDBChild, the backgroundSaveDoneHandler will terminate with success. Turns out that even if the child didn't yet exit, there's a chance it'll still miss our signal and exit with success. in that case, we will still mess up the dirty counter (deducting dirty_before_bgsave) which is reset by FLUSHALL, and override the synchronous rdb file we saved. instead, we'll set a flag to treat the next done handler as a failed one.
-
- 17 Jul, 2024 1 commit
-
-
Oran Agra authored
When the tests are run against an external server in this order: `--single unit/introspection --single unit/moduleapi/blockonbackground --single integration/redis-cli` the test would hang when the "ASK redirect test" test attempts to create a listening socket (it fails, and then redis-cli itself hangs waiting for a non-responsive socket created by the introspection test). the reasons are: 1. the blockedbackground test includes util.tcl and resets the `::last_port_attempted` variable 2. the test in introspection didn't close the listening server, so it's still alive. 3. find_available_port doesn't properly detect the busy port, and it thinks that the port is free even though it's busy. fixing all 3 of these problems, even though fixing just one would be enough to let the test pass.
-
- 16 Jul, 2024 3 commits
-
-
Oran Agra authored
- when uploading server logs, make sure they don't overwrite each other. - sort the test units to get consistent order between them (following #13220) - backup and restore the entire server configuration, to protect one unit from config changes another unit performs
-
debing.sun authored
Nowdays we do not trigger LUA GC after loading lua script. This means that when a large number of scripts are loaded, such as when functions are propagating from the master to the replica, if the LUA scripts are never touched on the replica, the garbage might remain there indefinitely. Before this PR, we would share a gc_count between scripts and functions. This means that, under certain circumstances, the GC trigger for scripts and functions was not fair. For example, loading a large number of scripts followed by a small number of functions could result in the functions triggering GC. In this PR, we assign a unique `gc_count` to each of them, so the GC triggers between them will no longer affect each other. on the other hand, this PR will to bring regession for script loading commands(`FUNCTION LOAD` and `SCRIPT LOAD`), but they are not hot path, we can ignore it, and it will be replaced https://github.com/redis/redis/pull/13375 in the future. --------- Co-authored-by:
Oran Agra <oran@redislabs.com>
-
debing.sun authored
When we terminate the diskless RDB saving child process and, at the same time, we start a new BGSAVE for new replicas, we should not delete the RDB read event. Otherwise, these replicas will never receive a response. this is a result of the recent change in https://github.com/redis/redis/pull/13361 --------- Co-authored-by:
oranagra <oran@redislabs.com>
-
- 15 Jul, 2024 2 commits
-
-
debing.sun authored
This PR is based on the commits from PR https://github.com/valkey-io/valkey/pull/670. ## Description While exploring hotspots with profiling some benchmark workloads, we noticed the high cycles ratio of `prepareClientToWrite`, taking about 9% of the CPU of `smembers`, `lrange` commands. After deep dive the code logic, we thought we can gain the performance by reducing the redundant call of `prepareClientToWrite` when call addReply* continuously. For example: In https://github.com/valkey-io/valkey/blob/unstable/src/networking.c#L1080-L1082 , `prepareClientToWrite` is called three times in a row. --------- Signed-off-by:
Lipeng Zhu <lipeng.zhu@intel.com> Co-authored-by:
Lipeng Zhu <lipeng.zhu@intel.com> Co-authored-by:
Wangyang Guo <wangyang.guo@intel.com>
-
Oran Agra authored
test failure: ``` [err]: Interactive CLI: should find second search result if user presses ctrl+s in tests/integration/redis-cli.tcl Expected '1' to be equal to '0' (context: type eval line 10 cmd {assert_equal 1 [regexp {\(i-search\): \x1B\[0mk\x1B\[1mey\x1B\[0ms one} $result]} proc ::test) ``` this test (introduced in #12543) depends on the local history file, so it can fail if there's some match there. the fix is to use a different history file, and delete it before each run.
-
- 14 Jul, 2024 1 commit
-
-
guybe7 authored
128 is not enough chars when we're talking about commands like RESTORE. Of course, it's impossible to find the perfect number, but 1024 is better than 128, and it's not obscenely large.
-
- 12 Jul, 2024 1 commit
-
-
debing.sun authored
If `config resetstat` is executed and a defrag is started after it, the `total_active_defrag_time` will not be 0. When we start the defrag again, we will skip the following steps: 1. waiting for the defrag to start. (s total_active_defrag_time is equal 0) 2. waiting for the test to complete. (active_defrag_running is euqal 0) which result in the test failed. --------- Co-authored-by:
oranagra <oran@redislabs.com>
-
- 11 Jul, 2024 3 commits
-
-
debing.sun authored
The`Scripts do not block on waitaof` test keeps failing in the external CI: https://github.com/redis/redis/actions/runs/9875670156/job/27272955900?pr=13407 The main reason is that if AOF happens to be enabled, we get an acklocal of 1.
-
guybe7 authored
To be more similar to EXPIRE-like commands, which emit a "del" notification if the expire-time is in the past
-
guybe7 authored
This commit reverts the deletion of the condition `!bc->blocked_on_keys` that was accidentally introduced by https://github.com/redis/redis/pull/12817 . In case a blocked-on-keys module client is unblocked both `moduleUnblockClientOnKey` and `moduleHandleBlockedClients` are called which resulted in `updateStatsOnUnblock` being called twice Now, that `moduleHandleBlockedClients` doesn't call `updateStatsOnUnblock` in case of unblocked module key-blocked clients, in the unlikely event that the module decides to call `RM_UnblockClient` on a key-blocked client, we need to call `updateStatsOnUnblock` from within `moduleBlockedClientTimedOut`, but since `moduleBlockedClientTimedOut` is not tread-safe we can't call it directly from withing `RM_UnblockClient`. Added a new flag `blocked_on_keys_explicit_unblock` for that specific case, which will cause `moduleBlockedClientTimedOut` to be called from `moduleHandleBlockedClients` (which is only called from the main thread) --------- Co-authored-by:
debing.sun <debing.sun@redis.com>
-
- 10 Jul, 2024 1 commit
-
-
debing.sun authored
### Issue The current implementation of `FUNCTION FLUSH` command uses `lua_unref()` to unreference script closures in Lua vm. However, invoking `lua_unref()` during lazy free (`ASYNC` argument) is risky since it is not thread-safe. Another issue is that using `lua_unref()` to unreference references does not trigger GC, This can result in the Lua VM leaves a significant amount of garbage, which may never be cleaned up if not properly GC. ### Solution The proposed solution is to completely rebuild the engines, resulting in a brand new Lua VM. --------- Co-authored-by:
meir <meir@redis.com>
-
- 09 Jul, 2024 1 commit
-
-
debing.sun authored
This PR is based on the commits from PR #11747. In the event of an assertion failure, hide command arguments from the operator. In some cases, private client information can be voluntarily exposed when a redis instance crashes due to an assertion failure. This commit prevent וnintentional client info exposure. Operators can still access the hidden data, but they must actively request it. Any of the client info commands remains the unchanged. ### Config Add a new config `hide-user-data-from-log` to turn this feature on and off, default off. --------- Co-authored-by:
naglera <anagler123@gmail.com> Co-authored-by:
naglera <58042354+naglera@users.noreply.github.com>
-
- 08 Jul, 2024 1 commit
-
-
Vitah Lin authored
https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/ Due to GitHub removing support for CentOS 7 in GitHub Actions, all actions utilizing CentOS 7 need to be upgraded, upgrade the centos version from `contos:7` to `quay.io/centos/centos:stream9` which is the official RedHat centos container. Create some new actions named `old-chain` to verify support for gcc 4.8. This PR also includes the upgrade of actions/checkout from version 3 to version 4. --------- Co-authored-by:
debing.sun <debing.sun@redis.com>
-
- 07 Jul, 2024 1 commit
-
-
Moti Cohen authored
* Following this feature, Redis (ROF) may implement flow that allows hashes to be dumped directly from RDB to FLUSH without parsing. In this scenario, it is still essential to determine when to update hashes due to expired fields. By writing and reading the next minimum hash-field expiration before serializing objects to and from RDB, we can effectively track and expire hash fields without the need to parse the hash during loading. Before: #define RDB_TYPE_HASH_METADATA 22 #define RDB_TYPE_HASH_LISTPACK_EX 23 After: /* Hash with HFEs. Doesn't attach min TTL at start */ #define RDB_TYPE_HASH_METADATA_PRE_GA 22 /* Hash LP with HFEs. Doesn't attach min TTL at start */ #define RDB_TYPE_HASH_LISTPACK_EX_PRE_GA 23 /* Hash with HFEs. Attach min TTL at start */ #define RDB_TYPE_HASH_METADATA 24 /* Hash LP with HFEs. Attach min TTL at start */ #define RDB_TYPE_HASH_LISTPACK_EX 25 * Manually test loading RDB file before the change and verify hash and its HFEs is as expected. * Added `subexpires` counter to `redis-check-rdb`
-
- 04 Jul, 2024 1 commit
-
-
debing.sun authored
1. Add help for `DEBUG SCRIPT` command. 2. Remove a duplicate `getLuaScripts()` which is same as `evalScriptsDict()`.
-
- 03 Jul, 2024 1 commit
-
-
Filipe Oliveira (Redis) authored
The following PR does the following changes based upon on CPU profile info. The `getNodeByQuery` function represents 8.2% of an overhead of 12.3% when comparing single shard cluster with standalone. Proposed changes: - inlinging keyHashSlot to reduce overhead of that function call - Reduce duplicate calls to getCommandFlags within getNodeByQuery The above changes represent an improvement of approximately 5% on the achievable ops/sec. Co-authored-by:
filipecosta90 <filipecosta.90@gmail.com>
-
- 02 Jul, 2024 3 commits
-
-
Moti Cohen authored
* INFO command : rename `hashes_with_expiry_fields` to `subexpiry` * INFO command : rename `expired_hash_fields` to `expired_subkeys` * Fix statistic of `expired_subkeys` to count also lazy expired * Remove TODOs comments leftover in TCL * Fix potential flaky test of rdb load of hash-field-expiration
-
debing.sun authored
1. Update macOS version in GitHub Actions due to deprecation of macOS 11 Because the macOS 11 runner image will be removed by 06/28/2024. 2. CentOS has arrived at EOL, we need to update the yum repo to new url.
-
David Dougherty authored
This PR removes the Hugo frontmatter from this utility.
-
- 01 Jul, 2024 2 commits
-
-
Oran Agra authored
If we run FLUSHALL when the 'save' config is set, and there's a fork child ding BGSAVE, there's a chance the child is already finished, and the parent process is unaware of it. in that case the child will not get the kill signal and will finish successfully, but the parent process thinks it killed it and will reset the dirty counter to 0, then the backgroundSaveDoneHandlerDisk method can set the dirty counter to a negative value.
-
Oran Agra authored
getKeysUsingKeySpece had the range check AFTER the allocation, of the keys buffer, which could lead to an OOM panic when invalid arguments are provided, leading to an overflow. The allocated memory is only used after the range check, so there's no risk of buffer overrun. The OOM panic can happen on 32bit builds, or 64 builds running on systems with less than 4GB of RAM, and is reachable via the COMMAND GETKEYSANDFLAGS, and ACL key name validation.
-
- 27 Jun, 2024 3 commits
-
-
YaacovHazan authored
Upgrade urgency LOW: This is the second Release Candidate for Redis 7.4. Performance and resource utilization improvements ================================================= * #13296 Optimize CPU cache efficiency Changes to new 7.4 new features (compared to 7.4 RC1) ===================================================== * #13343 Hash - expiration of individual fields: when key does not exist - reply with an array (nonexisting code for each field) * #13329 Hash - expiration of individual fields: new keyspace event: `hexpired` Modules API - Potentially breaking changes to new 7.4 features (compared to 7.4 RC1) ==================================================================================== * #13326 Hash - expiration of individual fields: avoid lazy expire when called from a Modules API function
-
YaacovHazan authored
-
YaacovHazan authored
-
- 26 Jun, 2024 2 commits
-
-
Moti Cohen authored
There was wrong preliminary assumption that we can optionally provide vector of arguments more than count. This is error-prone approach that leaded to actual error in that case. This PR enforce that vector of argument match count. Also fixed flaky HRANDFIELD test.
-
debing.sun authored
In certain situations, we might generate a large number of propagates (e.g., multi/exec, Lua script, or a single command generating tons of propagations) within an event loop. During the process of propagating to a replica, if the replica is disconnected(marked as CLIENT_CLOSE_ASAP) due to exceeding the output buffer limit, we should remove its reference to the global replication buffer to avoid the global replication buffer being unable to be properly trimmed due to being referenced. --------- Co-authored-by:
oranagra <oran@redislabs.com>
-
- 25 Jun, 2024 1 commit
-
-
Moti Cohen authored
H(P)EXPIREAT command might delete fields in case the absolute time is in the past. Those HDELs need to be propagated as well. In general, as we need to propagate H(P)EXPIRE(AT) command to the replica, each field that is mentioned in the command should be categorized into one of the four options: 1. Managed to update field’s expiration time - propagate it to replica as part of the HPEXPIREAT command. 2. Deleted the field because the time is in the past - propagate also HDEL command to delete the field and remove the field from the propagated HPEXPIREAT. 3. Condition not met for the field - Remove the field from the propagated HPEXPIREAT command. 4. Field does not exists - Remove the field from the propagated HPEXPIREAT command. If none of the provided fields match option number 1, then avoid also propagating the HPEXPIREAT command to the replica. This approach is aligned with the EXPIRE command: If a given key has already expired, then DEL will be propagated instead of EXPIRE command. If condition not met, then command will be rejected. Otherwise, EXPIRE command will be propagated for given key.
-
- 24 Jun, 2024 1 commit
-
-
Moti Cohen authored
Considerations for the selected imp of HRANDFIELD & HFE feature: HRANDFIELD might access any of the fields in the hash as some of them might be expired. And so the Implementation of HRANDFIELD along with HFEs might be one of the two options: 1. Expire hash-fields before diving into handling HRANDFIELD. 2. Refine HRANDFIELD cases to deal with expired fields. Regarding the first option, as reference, the command RANDOMKEY also declareson O(1) complexity, yet might be stuck on a very long (but not infinite) loop trying to find non-expired keys. Furthermore RANDOMKEY also evicts expired keys along the way even though it is categorized as a read-only command. Note that the case of HRANDFIELD is more lightweight versus RANDOMKEY since HFEs have much more effective and aggressive active-expiration for fields behind. The second option introduces additional implementation complexity to HRANDFIELD. We could further refine HRANDFIELD cases to differentiate between scenarios with many expired fields versus few expired fields, and adjust based on the percentage of expired fields. However, this approach could still lead to long loops or necessitate expiring fields before selecting them. For the “lightweight” cases it is also expected to have a lightweight expiration. Considering the pros and cons, and the fact that HRANDFIELD is an infrequent command (particularly with HFEs) and the fact we have effective active-expiration behind for hash-fields, it is better to keep it simple and choose option number 1. Other changes: * Don't mark command dirty by internal hashTypeExpire(). It causes to read only command of HRANDFIELD to be accidently propagated (This flag should be indicated at higher level, by the command functions). * Align `hashTypeExpireIfNeeded()` and `hashTypeGetValue()` to be more aligned with `expireIfNeeded()` logic of keyspace.
-
- 21 Jun, 2024 2 commits
-
-
AcherTT authored
Add two new debug commands for outputing script. 1. `DEBUG SCRIPT LIST` Output all scripts. 2. `DEBUG SCRIPT <sha1>` Output a specific script. Close #3846
-
debing.sun authored
Related to #12647 1. Make clear that `RM_Replicate` and `RM_ReplicateVerbatim` are non-thread safe. 2. Make clear that `RM_Replicate` and `RM_ReplicateVerbatim` are alwarys wrapped into MULTI in any case.
-
- 20 Jun, 2024 1 commit
-
-
Moti Cohen authored
As part of HFE feature, the logic of rdbLoadObject() was wrongly modified to indicate of loaded empty hash from RDB as hash that all its fields got expired. Rollback to `emptykey` logic. This function should load blindly all fields, expired or not. Manually verified. Few more minor fixes: - remove hash double check of emptyKey - Fix from `sds` to `hfield` in rdbLoadObject() (not really a bug. Both are of type char*) - Revert code rdbLoadObject() to get dbid instead of db
-