CI / build-libc-malloc (push) Waiting to runDetails
CI / build-centos-jemalloc (push) Waiting to runDetails
CI / build-old-chain-jemalloc (push) Waiting to runDetails
Codecov / code-coverage (push) Waiting to runDetails
External Server Tests / test-external-standalone (push) Waiting to runDetails
External Server Tests / test-external-cluster (push) Waiting to runDetails
External Server Tests / test-external-nodebug (push) Waiting to runDetails
Spellcheck / Spellcheck (push) Waiting to runDetails
Fix https://github.com/redis/redis/pull/13853#pullrequestreview-2675227138
This PR ensures that the client's current command is not reset by
unblockClient(), while still needing to be handled after `unblockclient()`.
The FLUSH command still requires reprocessing (update the replication
offset) after unblockClient(). Therefore, we mark such blocked clients
with the CLIENT_PENDING_COMMAND flag to prevent the command from being
reset during unblockClient().
CI / build-libc-malloc (push) Has been cancelledDetails
CI / build-centos-jemalloc (push) Has been cancelledDetails
CI / build-old-chain-jemalloc (push) Has been cancelledDetails
Codecov / code-coverage (push) Has been cancelledDetails
External Server Tests / test-external-standalone (push) Has been cancelledDetails
External Server Tests / test-external-cluster (push) Has been cancelledDetails
External Server Tests / test-external-nodebug (push) Has been cancelledDetails
Spellcheck / Spellcheck (push) Has been cancelledDetails
After https://github.com/redis/redis/pull/13167, when a client calls
`FLUSHDB` command, we still async empty database, and the client was
blocked until the lazyfree completes.
1) If another client calls `SLAVEOF` command during this time, the
server will unblock all blocked clients, including those blocked by the
lazyfree. However, when unblocking a lazyfree blocked client, we forgot
to call `updateStatsOnUnblock()`, which ultimately triggered the
following assertion.
2) If a client blocked by Lazyfree is unblocked midway, and at this
point the `bio_comp_list` has already received the completion
notification for the bio, we might end up processing a client that has
already been unblocked in `flushallSyncBgDone()`. Therefore, we need to
filter it out.
---------
Co-authored-by: oranagra <oran@redislabs.com>
After https://github.com/redis/redis/pull/13816, we make a new API to
defrag RedisModuleDict.
Currently, we only support incremental defragmentation of the dictionary
itself, but the defragmentation of values is still not incremental. If
the values are very large, it could lead to significant blocking.
Therefore, in this PR, we have added incremental defragmentation for the
values.
The main change is to the `RedisModuleDefragDictValueCallback`, we
modified the return value of this callback.
When the callback returns 1, we will save the `seekTo` as the key of the
current unfinished node, and the next time we enter, we will continue
defragmenting this node.
When the return value is 0, we will proceed to the next node.
## Test
Since each dictionary in the global dict originally contained only 10
strings, but now it has been changed to a nested dictionary, each
dictionary now has 10 sub-dictionaries, with each sub-dictionary
containing 10 strings, this has led to a corresponding reduction in the
defragmentation time obtained from other tests.
Therefore, the other tests have been modified to always wait for
defragmentation to be turned off before the test begins, then start it
after creating fragmentation, ensuring that they can always run for a
full defragmentation cycle.
---------
Co-authored-by: ephraimfeldblum <ephraim.feldblum@redis.com>
Now attributes are added as well. Moreover the code no longer uses
the first node to guess the size of the items, but does an average
of the few first items/attributes found. Still O(1) but more precise.
debing.sun
antirez
YaacovHazan
kei-nan
YaacovHazan
YaacovHazan
Eran Hadad
DvirDukhan
Rowan Trollope