Redis 6.2 rc2 #8305
Merged
Redis 6.2 rc2 #8305
Conversation
This file contains 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
Fix wrong server dirty increment in * spopWithCountCommand * hsetCommand * ltrimCommand * pfaddCommand Some didn't increment the amount of fields (just one per command). Others had excessive increments.
…edis#8154) If we only has one node in cluster or before 8fdc857, we don't know myself ip, so we should use config.hostip for myself. However, we should use the IP from the command response to update node->ip if it exists and is different from config.hostip otherwise, when there's more than one node in cluster, if we use -h with virtual IP or DNS, benchmark doesn't show node real ip and port of myself even though it could get right IP and port by CLUSTER NODES command.
mostly signed / unsigned mismatches. Signed-off-by: Hanif Bin Ariffin <hanif.ariffin.4326@gmail.com> Co-authored-by: Oran Agra <oran@redislabs.com>
…edis#8200) * Handle binary safe string for REQUIREPASS and MASTERAUTH directives.
…dis#5954) In response to large client query buffer optimization introduced in 1898e6c. The calculation of the amount of remaining bytes we need to write to the query buffer was calculated wrong, as a result we are unnecessarily growing the client query buffer by sdslen(c->querybuf) always. This fix corrects that behavior. Please note the previous behavior prior to the before-mentioned change was correctly calculating the remaining additional bytes, and this change makes that calculate to be consistent. Useful context, the argument of size `ll` starts at qb_pos (which is now the beginning of the sds), but much of it may have already been read from the socket, so we only need to grow the sds for the remainder of it.
- Mark it as a @hyperloglog command (ACL) - Should not be allowed in OOM - Add firstkey, lastkey, step - Add comment that explains the 'write' flag
* Fix some redundancy use of semicolon in do-while macros
…EXEC to propagate MULTI (redis#8216) In the distant history there was only the read flag for commands, and whatever command that didn't have the read flag was a write one. Then we added the write flag, but some portions of the code still used !read Also some commands that don't work on the keyspace at all, still have the read flag. Changes in this commit: 1. remove the read-only flag from TIME, ECHO, ROLE and LASTSAVE 2. EXEC command used to decides if it should propagate a MULTI by looking at the command flags (!read & !admin). When i was about to change it to look at the write flag instead, i realized that this would cause it not to propagate a MULTI for PUBLISH, EVAL, and SCRIPT, all 3 are not marked as either a read command or a write one (as they should), but all 3 are calling forceCommandPropagation. So instead of introducing a new flag to denote a command that "writes" but not into the keyspace, and still needs propagation, i decided to rely on the forceCommandPropagation, and just fix the code to propagate MULTI when needed rather than depending on the command flags at all. The implication of my change then is that now it won't decide to propagate MULTI when it sees one of these: SELECT, PING, INFO, COMMAND, TIME and other commands which are neither read nor write. 3. Changing getNodeByQuery and clusterRedirectBlockedClientIfNeeded in cluster.c to look at !write rather than read flag. This should have no implications, since these code paths are only reachable for commands which access keys, and these are always marked as either read or write. This commit improve MULTI propagation tests, for modules and a bunch of other special cases, all of which used to pass already before that commit. the only one that test change that uncovered a change of behavior is the one that DELs a non-existing key, it used to propagate an empty multi-exec block, and no longer does.
Normally IO threads should simply read data from the socket into the buffer and attempt to parse it. If a protocol error is detected, a reply is generated which may result with installing a write handler which is not thread safe. This fix delays that until the client is processed back in the main thread. Fixes redis#8220
Turns out that when the fork child crashes, the crash log was deleting the pidfile from the disk (although the parent is still running. Now we set the pidfile of the fork process to NULL so the fork process will never deletes it.
Homebrew for darwin-arm64 uses /opt/homebrew instead of /usr/local as the prefix, so that it can coexist with darwin-x86_64 using Rosetta 2.
This isn't a leak, just an warning due to unreachable allocation on the fork child. Problem created by 92a483b
When a database on a 64 bit build grows past 2^31 keys, the underlying hash table expands to 2^32 buckets. After this point, the algorithms for selecting random elements only return elements from half of the available buckets because they use random() which has a range of 0 to 2^31 - 1. This causes problems for eviction policies which use dictGetSomeKeys or dictGetRandomKey. Over time they cause the hash table to become unbalanced because, while new keys are spread out evenly across all buckets, evictions come from only half of the available buckets. Eventually this half of the table starts to run out of keys and it takes longer and longer to find candidates for eviction. This continues until no more evictions can happen. This solution addresses this by using a 64 bit PRNG instead of libc random(). Co-authored-by: Greg Femec <gfemec@google.com>
…dis#8213) Apparently the "leaks" took reports a different error string about process that's not found in each version of MacOS. This cause the test suite to fail on some OS versions, since some tests terminate the process before looking for leaks. Instead of looking at the error string, we now look at the (documented) exit code.
Properly throw errors for invalid replication stream and support redis#8217
Cleanup key tracking documentation, always cleanup the tracking table, and free the tracking table in an async manner when applicable.
As discussed in redis#7364, it is good to have a HELLO command variant, which does not switch the current proto version of a redis server. While `HELLO` will work, it introduced a certain difficulty on parsing options of the command. We will need to offset the index of authentication and setname option by -1. So 0 is marked a special version meaning non-switching. And we do not need to change the code much.
Signed-off-by: xhe <xw897002528@gmail.com>
Signed-off-by: xhe <xw897002528@gmail.com>
Signed-off-by: xhe <xw897002528@gmail.com>
- the last COW report wasn't always read from the pipe (receiveLastChildInfo wasn't used) - but in fact, there's no reason we won't always try to drain that pipe so i'm unifying receiveLastChildInfo with receiveChildInfo - adjust threshold of the COW test when run in accurate mode - add some prints in case this test fails again - fix indentation, page size, and PID! in MacOS proc info p.s. it seems that pri_pages_dirtied is always 0
Co-authored-by: Oran Agra <oran@redislabs.com>
…8302) When the server state changes and blocked clients are being dropped, the paused clients should not be dropped, they're safe to keep since unlike other blocked types, these commands are not half way though processing, and the commands they sent may get rejected according to the new server state.
Assert that clusterAddNode can't fail
oranagra
commented
Jan 11, 2021
yossigo
reviewed
Jan 11, 2021
oranagra
force-pushed
the
redis_6.2_rc2
branch
from
f4f0930
to
a70be17
Compare
itamarhaber
previously approved these changes
Jan 11, 2021
yossigo
previously approved these changes
Jan 11, 2021
madolson
reviewed
Jan 11, 2021
Saving string of more than 2GB to the RDB file, can result in corrupt RDB, or failure in rdbSave. S
The test was trying to wait for the replica to start loading the rdb from the master before it kills the master, but it was actually waiting for ROLE to be in "sync" mode, which corresponds to REPL_STATE_TRANSFER that starts before the actual loading starts. now instead it waits for the loading flag to be set. Besides, the test was dependent on the previous configuration of the servers, relying on the fact the replica is configured to persist (either RDB of AOF), now it is set explicitly.
This fixes three issues: 1. Using debug SLEEP was impacting the subsequent test, and causing it to pass reliably even though it should have failed. There was exactly 5 seconds of artificial pause (after 1000, wait 3000, wait 1000) between the debug sleep 5 and when we needed to unblock the client in the subsequent test. Now the test properly makes sure the client is unblocked, and the subsequent test is fixed. 2. Minor, the client pause types were using & comparisons instead of ==, since it was previously a flag. 3. Test is faster now that some of the hand wavy time is removed.
we didn't wait for the commands executed on the master to reach the replica.
oranagra
force-pushed
the
redis_6.2_rc2
branch
from
a70be17
to
a7364e5
Compare
yossigo
previously approved these changes
Jan 12, 2021
oranagra
force-pushed
the
redis_6.2_rc2
branch
from
a7364e5
to
9f18e28
Compare
yossigo
approved these changes
Jan 12, 2021
itamarhaber
approved these changes
Jan 12, 2021
oranagra
force-pushed
the
redis_6.2_rc2
branch
from
9f18e28
to
049f2f0
Compare
6 tasks
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.
@redis/core-team please approve.
This is basically what's in unstable with additional release notes.
Upgrade urgency LOW: This is the second Release Candidate of Redis 6.2.
IMPORTANT: If you're running Redis on ARM64 or a big-endian system, upgrade may
have significant implications. Please be sure to read the notes below.
Here is a comprehensive list of changes in this release compared to 6.2 RC1,
each one includes the PR number that added it, so you can get more details
at https://github.com/redis/redis/pull/
New commands / args:
Command behavior changes:
Other behavior changes:
Bug fixes with compatibility implications (bugs introduced in Redis 6.0):
If you're using big-endian please consider the compatibility implications with
RESTORE, replication and persistence.
If your scripts use redis.setresp() or return a map (new in Redis 6.0), please
consider the implications.
Bug fixes that are only applicable to previous releases of Redis 6.2:
Bug fixes:
Additional improvements:
Platform and deployment-related changes:
Due to the potential severity of this issue, Redis will refuse to run on
affected platforms by default.
Info fields and introspection changes:
Module API changes: