mirror of https://mirror.osredm.com/root/redis.git
Remove incomplete fix of a broader problem (#10013)
Preventing COFIG SET maxmemory from propagating is just the tip of the iceberg. Module that performs a write operation in a notification can cause any command to be propagated, based on server.dirty We need to come up with a better solution.
This commit is contained in:
parent
2c5573e894
commit
266d95066d
|
@ -2207,9 +2207,6 @@ static int updateMaxmemory(const char **err) {
|
||||||
}
|
}
|
||||||
performEvictions();
|
performEvictions();
|
||||||
}
|
}
|
||||||
/* The function is called via 'CONFIG SET maxmemory', we don't want to propagate it
|
|
||||||
* because server.dirty might have been incremented by performEvictions() */
|
|
||||||
preventCommandPropagation(server.current_client);
|
|
||||||
return 1;
|
return 1;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -174,6 +174,7 @@ tags "modules" {
|
||||||
|
|
||||||
# Note whenever there's double notification: SET with EX issues two separate
|
# Note whenever there's double notification: SET with EX issues two separate
|
||||||
# notifications: one for "set" and one for "expire"
|
# notifications: one for "set" and one for "expire"
|
||||||
|
# "config set" should not be here, see https://github.com/redis/redis/issues/10014
|
||||||
assert_replication_stream $repl {
|
assert_replication_stream $repl {
|
||||||
{select *}
|
{select *}
|
||||||
{multi}
|
{multi}
|
||||||
|
@ -197,6 +198,7 @@ tags "modules" {
|
||||||
{del asdf*}
|
{del asdf*}
|
||||||
{incr notifications}
|
{incr notifications}
|
||||||
{del asdf*}
|
{del asdf*}
|
||||||
|
{config set maxmemory 1}
|
||||||
{multi}
|
{multi}
|
||||||
{incr notifications}
|
{incr notifications}
|
||||||
{set asdf4 4}
|
{set asdf4 4}
|
||||||
|
|
Loading…
Reference in New Issue