| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
37a10cef introduced automatic wrapping of MULTI/EXEC for the
alsoPropagate API. However this collides with the built-in mechanism
already present in module.c. To avoid complex changes near Redis 6 GA
this commit introduces the ability to exclude call() MUTLI/EXEC wrapping
for also propagate in order to continue to use the old code paths in
module.c.
|
| | |
|
| |\ |
|
| | |\
| | |
| | | |
fix: dict.c->dictResize()->minimal type
|
| | | | |
|
| | |\ \
| | | |
| | | | |
PSYNC2: reset backlog_idx and master_repl_offset correctly
|
| | |/ / |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now that this mechanism is the sole one used for blocked clients
timeouts, it is more wise to cleanup the table when the client unblocks
for any reason. We use a flag: CLIENT_IN_TO_TABLE, in order to avoid a
radix tree lookup when the client was already removed from the table
because we processed it by scanning the radix tree.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| | |
See #7002.
|
| |\ \
| | |
| | | |
AOFRW on an empty stream created with MKSTREAM loads badkly
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the AOF will be loaded successfully, but the stream will be missing,
i.e inconsistencies with the original db.
this was because XADD with id of 0-0 would error.
add a test to reproduce.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A very commonly signaled operational problem with Redis master-replicas
sets is that, once the master becomes unavailable for some reason,
especially because of network problems, many times it wont be able to
perform a partial resynchronization with the new master, once it rejoins
the partition, for the following reason:
1. The master becomes isolated, however it keeps sending PINGs to the
replicas. Such PINGs will never be received since the link connection is
actually already severed.
2. On the other side, one of the replicas will turn into the new master,
setting its secondary replication ID offset to the one of the last
command received from the old master: this offset will not include the
PINGs sent by the master once the link was already disconnected.
3. When the master rejoins the partion and is turned into a replica, its
offset will be too advanced because of the PINGs, so a PSYNC will fail,
and a full synchronization will be required.
Related to issue #7002 and other discussion we had in the past around
this problem.
|
| | | |
| | |
| | |
| | | |
Related to #7022.
|
| |\ \ \
| | | |
| | | | |
MULTI/EXEC during LUA script timeout are messed up
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Redis refusing to run MULTI or EXEC during script timeout may cause partial
transactions to run.
1) if the client sends MULTI+commands+EXEC in pipeline without waiting for
response, but these arrive to the shards partially while there's a busy script,
and partially after it eventually finishes: we'll end up running only part of
the transaction (since multi was ignored, and exec would fail).
2) similar to the above if EXEC arrives during busy script, it'll be ignored and
the client state remains in a transaction.
the 3rd test which i added for a case where MULTI and EXEC are ok, and
only the body arrives during busy script was already handled correctly
since processCommand calls flagTransaction
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
Added BITFIELD_RO variants for read-only operations.
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Allow RM_GetContextFlags to work with ctx==NULL
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | | |
fix potential memory leak in redis-cli lua debug mode
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
Fix issues with failed/rejected accepts.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We assume accept handlers may choose to reject a connection and close
it, but connAccept() callers can't distinguish between this state and
other error states requiring connClose().
This makes it safe (and mandatory!) to always call connClose() if
connAccept() fails, and safe for accept handlers to close connections
(which will defer).
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
Fix Bug for Client Side Caching: Unexpected Behaviour when Switching between OPTIN/OPTOUT Mode
|
| | | | | | | |
|
| | | |_|/ /
| |/| | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | | |
add missing commands description in cluster help
|
| | |/ / / / |
|
| |\ \ \ \ \
| |/ / / / |
|
| | |\ \ \ \
| | | | | |
| | | | | | |
Support Redis Cluster Proxy PROXY INFO command
|
| | | | | | | |
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | | |
Update redis.conf
|
