2021-06-09 08:13:24 -04:00
|
|
|
proc wait_for_dbsize {size} {
|
|
|
|
set r2 [redis_client]
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[$r2 dbsize] == $size
|
|
|
|
} else {
|
|
|
|
fail "Target dbsize not reached"
|
|
|
|
}
|
|
|
|
$r2 close
|
|
|
|
}
|
|
|
|
|
2012-11-17 05:17:54 -05:00
|
|
|
start_server {tags {"multi"}} {
|
2022-01-05 03:16:04 -05:00
|
|
|
test {MULTI / EXEC basics} {
|
2012-11-17 05:17:54 -05:00
|
|
|
r del mylist
|
|
|
|
r rpush mylist a
|
|
|
|
r rpush mylist b
|
|
|
|
r rpush mylist c
|
|
|
|
r multi
|
|
|
|
set v1 [r lrange mylist 0 -1]
|
|
|
|
set v2 [r ping]
|
|
|
|
set v3 [r exec]
|
|
|
|
list $v1 $v2 $v3
|
|
|
|
} {QUEUED QUEUED {{a b c} PONG}}
|
|
|
|
|
|
|
|
test {DISCARD} {
|
|
|
|
r del mylist
|
|
|
|
r rpush mylist a
|
|
|
|
r rpush mylist b
|
|
|
|
r rpush mylist c
|
|
|
|
r multi
|
|
|
|
set v1 [r del mylist]
|
|
|
|
set v2 [r discard]
|
|
|
|
set v3 [r lrange mylist 0 -1]
|
|
|
|
list $v1 $v2 $v3
|
|
|
|
} {QUEUED OK {a b c}}
|
|
|
|
|
|
|
|
test {Nested MULTI are not allowed} {
|
|
|
|
set err {}
|
|
|
|
r multi
|
|
|
|
catch {[r multi]} err
|
|
|
|
r exec
|
|
|
|
set _ $err
|
|
|
|
} {*ERR MULTI*}
|
|
|
|
|
|
|
|
test {MULTI where commands alter argc/argv} {
|
|
|
|
r sadd myset a
|
|
|
|
r multi
|
|
|
|
r spop myset
|
|
|
|
list [r exec] [r exists myset]
|
|
|
|
} {a 0}
|
|
|
|
|
|
|
|
test {WATCH inside MULTI is not allowed} {
|
|
|
|
set err {}
|
|
|
|
r multi
|
|
|
|
catch {[r watch x]} err
|
|
|
|
r exec
|
|
|
|
set _ $err
|
|
|
|
} {*ERR WATCH*}
|
|
|
|
|
2012-11-17 06:09:17 -05:00
|
|
|
test {EXEC fails if there are errors while queueing commands #1} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r del foo1{t} foo2{t}
|
2012-11-17 06:09:17 -05:00
|
|
|
r multi
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo1{t} bar1
|
2012-11-17 06:09:17 -05:00
|
|
|
catch {r non-existing-command}
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo2{t} bar2
|
2012-11-17 06:09:17 -05:00
|
|
|
catch {r exec} e
|
|
|
|
assert_match {EXECABORT*} $e
|
2021-06-09 08:13:24 -04:00
|
|
|
list [r exists foo1{t}] [r exists foo2{t}]
|
2012-11-17 06:09:17 -05:00
|
|
|
} {0 0}
|
|
|
|
|
|
|
|
test {EXEC fails if there are errors while queueing commands #2} {
|
|
|
|
set rd [redis_deferring_client]
|
2021-06-09 08:13:24 -04:00
|
|
|
r del foo1{t} foo2{t}
|
2012-11-17 06:09:17 -05:00
|
|
|
r multi
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo1{t} bar1
|
2012-11-17 06:09:17 -05:00
|
|
|
$rd config set maxmemory 1
|
2012-11-29 10:12:14 -05:00
|
|
|
assert {[$rd read] eq {OK}}
|
2021-06-09 08:13:24 -04:00
|
|
|
catch {r lpush mylist{t} myvalue}
|
2012-11-17 06:09:17 -05:00
|
|
|
$rd config set maxmemory 0
|
2012-11-29 10:12:14 -05:00
|
|
|
assert {[$rd read] eq {OK}}
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo2{t} bar2
|
2012-11-17 06:09:17 -05:00
|
|
|
catch {r exec} e
|
|
|
|
assert_match {EXECABORT*} $e
|
|
|
|
$rd close
|
2021-06-09 08:13:24 -04:00
|
|
|
list [r exists foo1{t}] [r exists foo2{t}]
|
|
|
|
} {0 0} {needs:config-maxmemory}
|
2012-11-17 06:09:17 -05:00
|
|
|
|
2012-11-17 06:11:13 -05:00
|
|
|
test {If EXEC aborts, the client MULTI state is cleared} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r del foo1{t} foo2{t}
|
2012-11-17 06:11:13 -05:00
|
|
|
r multi
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo1{t} bar1
|
2012-11-17 06:11:13 -05:00
|
|
|
catch {r non-existing-command}
|
2021-06-09 08:13:24 -04:00
|
|
|
r set foo2{t} bar2
|
2012-11-17 06:11:13 -05:00
|
|
|
catch {r exec} e
|
|
|
|
assert_match {EXECABORT*} $e
|
|
|
|
r ping
|
|
|
|
} {PONG}
|
|
|
|
|
2010-05-25 08:04:46 -04:00
|
|
|
test {EXEC works on WATCHed key not modified} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r watch x{t} y{t} z{t}
|
|
|
|
r watch k{t}
|
2010-05-25 08:04:46 -04:00
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
|
|
|
test {EXEC fail on WATCHed key modified (1 key of 1 watched)} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r set x 40
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {}
|
|
|
|
|
|
|
|
test {EXEC fail on WATCHed key modified (1 key of 5 watched)} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r set x{t} 30
|
|
|
|
r watch a{t} b{t} x{t} k{t} z{t}
|
|
|
|
r set x{t} 40
|
2010-05-25 08:04:46 -04:00
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {}
|
|
|
|
|
2012-01-30 01:36:49 -05:00
|
|
|
test {EXEC fail on WATCHed key modified by SORT with STORE even if the result is empty} {
|
|
|
|
r flushdb
|
|
|
|
r lpush foo bar
|
|
|
|
r watch foo
|
|
|
|
r sort emptylist store foo
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {cluster:skip}
|
2012-01-30 01:36:49 -05:00
|
|
|
|
2021-07-11 06:17:23 -04:00
|
|
|
test {EXEC fail on lazy expired WATCHed key} {
|
2022-02-23 01:47:16 -05:00
|
|
|
r del key
|
2021-07-11 06:17:23 -04:00
|
|
|
r debug set-active-expire 0
|
|
|
|
|
2022-02-23 01:47:16 -05:00
|
|
|
for {set j 0} {$j < 10} {incr j} {
|
|
|
|
r set key 1 px 100
|
|
|
|
r watch key
|
|
|
|
after 101
|
|
|
|
r multi
|
|
|
|
r incr key
|
2021-07-11 06:17:23 -04:00
|
|
|
|
2022-02-23 01:47:16 -05:00
|
|
|
set res [r exec]
|
|
|
|
if {$res eq {}} break
|
|
|
|
}
|
|
|
|
if {$::verbose} { puts "EXEC fail on lazy expired WATCHed key attempts: $j" }
|
2021-07-11 06:17:23 -04:00
|
|
|
|
|
|
|
r debug set-active-expire 1
|
2022-02-23 01:47:16 -05:00
|
|
|
set _ $res
|
|
|
|
} {} {needs:debug}
|
2021-07-11 06:17:23 -04:00
|
|
|
|
2022-02-22 05:09:46 -05:00
|
|
|
test {WATCH stale keys should not fail EXEC} {
|
|
|
|
r del x
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r set x foo px 1
|
|
|
|
after 2
|
|
|
|
r watch x
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {needs:debug}
|
|
|
|
|
|
|
|
test {Delete WATCHed stale keys should not fail EXEC} {
|
|
|
|
r del x
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r set x foo px 1
|
|
|
|
after 2
|
|
|
|
r watch x
|
|
|
|
# EXISTS triggers lazy expiry/deletion
|
|
|
|
assert_equal 0 [r exists x]
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {needs:debug}
|
|
|
|
|
|
|
|
test {FLUSHDB while watching stale keys should not fail EXEC} {
|
|
|
|
r del x
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r set x foo px 1
|
|
|
|
after 2
|
|
|
|
r watch x
|
|
|
|
r flushdb
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {needs:debug}
|
|
|
|
|
2010-05-25 08:04:46 -04:00
|
|
|
test {After successful EXEC key is no longer watched} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
r set x 40
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
|
|
|
test {After failed EXEC key is no longer watched} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r set x 40
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
r set x 40
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
|
|
|
test {It is possible to UNWATCH} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r set x 40
|
|
|
|
r unwatch
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
|
|
|
test {UNWATCH when there is nothing watched works as expected} {
|
|
|
|
r unwatch
|
|
|
|
} {OK}
|
2010-05-25 13:30:24 -04:00
|
|
|
|
|
|
|
test {FLUSHALL is able to touch the watched keys} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r flushall
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {}
|
|
|
|
|
|
|
|
test {FLUSHALL does not touch non affected keys} {
|
|
|
|
r del x
|
|
|
|
r watch x
|
|
|
|
r flushall
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
|
|
|
test {FLUSHDB is able to touch the watched keys} {
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r flushdb
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {}
|
|
|
|
|
|
|
|
test {FLUSHDB does not touch non affected keys} {
|
|
|
|
r del x
|
|
|
|
r watch x
|
|
|
|
r flushdb
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {PONG}
|
|
|
|
|
2021-01-04 07:48:28 -05:00
|
|
|
test {SWAPDB is able to touch the watched keys that exist} {
|
|
|
|
r flushall
|
|
|
|
r select 0
|
|
|
|
r set x 30
|
|
|
|
r watch x ;# make sure x (set to 30) doesn't change (SWAPDB will "delete" it)
|
|
|
|
r swapdb 0 1
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {singledb:skip}
|
2021-01-04 07:48:28 -05:00
|
|
|
|
|
|
|
test {SWAPDB is able to touch the watched keys that do not exist} {
|
|
|
|
r flushall
|
|
|
|
r select 1
|
|
|
|
r set x 30
|
|
|
|
r select 0
|
|
|
|
r watch x ;# make sure the key x (currently missing) doesn't change (SWAPDB will create it)
|
|
|
|
r swapdb 0 1
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {singledb:skip}
|
2021-01-04 07:48:28 -05:00
|
|
|
|
2022-02-22 05:09:46 -05:00
|
|
|
test {SWAPDB does not touch watched stale keys} {
|
|
|
|
r flushall
|
|
|
|
r select 1
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r set x foo px 1
|
|
|
|
after 2
|
|
|
|
r watch x
|
|
|
|
r swapdb 0 1 ; # expired key replaced with no key => no change
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {singledb:skip needs:debug}
|
|
|
|
|
|
|
|
test {SWAPDB does not touch non-existing key replaced with stale key} {
|
|
|
|
r flushall
|
|
|
|
r select 0
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r set x foo px 1
|
|
|
|
after 2
|
|
|
|
r select 1
|
|
|
|
r watch x
|
|
|
|
r swapdb 0 1 ; # no key replaced with expired key => no change
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {singledb:skip needs:debug}
|
|
|
|
|
|
|
|
test {SWAPDB does not touch stale key replaced with another stale key} {
|
|
|
|
r flushall
|
|
|
|
r debug set-active-expire 0
|
|
|
|
r select 1
|
|
|
|
r set x foo px 1
|
|
|
|
r select 0
|
|
|
|
r set x bar px 1
|
|
|
|
after 2
|
|
|
|
r select 1
|
|
|
|
r watch x
|
|
|
|
r swapdb 0 1 ; # no key replaced with expired key => no change
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
assert_equal {PONG} [r exec]
|
|
|
|
r debug set-active-expire 1
|
|
|
|
} {OK} {singledb:skip needs:debug}
|
|
|
|
|
2010-05-25 13:30:24 -04:00
|
|
|
test {WATCH is able to remember the DB a key belongs to} {
|
|
|
|
r select 5
|
|
|
|
r set x 30
|
|
|
|
r watch x
|
|
|
|
r select 1
|
|
|
|
r set x 10
|
|
|
|
r select 5
|
|
|
|
r multi
|
|
|
|
r ping
|
2013-03-27 06:30:23 -04:00
|
|
|
set res [r exec]
|
|
|
|
# Restore original DB
|
|
|
|
r select 9
|
|
|
|
set res
|
2021-06-09 08:13:24 -04:00
|
|
|
} {PONG} {singledb:skip}
|
2010-07-05 13:38:12 -04:00
|
|
|
|
|
|
|
test {WATCH will consider touched keys target of EXPIRE} {
|
|
|
|
r del x
|
|
|
|
r set x foo
|
|
|
|
r watch x
|
|
|
|
r expire x 10
|
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
|
|
|
} {}
|
|
|
|
|
2020-10-22 05:57:45 -04:00
|
|
|
test {WATCH will consider touched expired keys} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r flushall
|
2010-07-05 13:38:12 -04:00
|
|
|
r del x
|
|
|
|
r set x foo
|
2011-11-25 06:27:00 -05:00
|
|
|
r expire x 1
|
2010-07-05 13:38:12 -04:00
|
|
|
r watch x
|
2021-06-09 08:13:24 -04:00
|
|
|
|
|
|
|
# Wait for the keys to expire.
|
|
|
|
wait_for_dbsize 0
|
|
|
|
|
2010-07-05 13:38:12 -04:00
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
r exec
|
2020-10-22 05:57:45 -04:00
|
|
|
} {}
|
2011-11-25 06:27:00 -05:00
|
|
|
|
|
|
|
test {DISCARD should clear the WATCH dirty flag on the client} {
|
|
|
|
r watch x
|
|
|
|
r set x 10
|
|
|
|
r multi
|
|
|
|
r discard
|
|
|
|
r multi
|
|
|
|
r incr x
|
|
|
|
r exec
|
|
|
|
} {11}
|
|
|
|
|
|
|
|
test {DISCARD should UNWATCH all the keys} {
|
|
|
|
r watch x
|
|
|
|
r set x 10
|
|
|
|
r multi
|
|
|
|
r discard
|
|
|
|
r set x 10
|
|
|
|
r multi
|
|
|
|
r incr x
|
|
|
|
r exec
|
|
|
|
} {11}
|
2013-03-27 06:31:27 -04:00
|
|
|
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
test {MULTI / EXEC is not propagated (single write command)} {
|
2013-03-27 06:31:27 -04:00
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
r exec
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
r set foo2 bar
|
2013-03-27 06:31:27 -04:00
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{set foo bar}
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
{set foo2 bar}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
|
|
|
} {} {needs:repl}
|
|
|
|
|
|
|
|
test {MULTI / EXEC is propagated correctly (multiple commands)} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r set foo{t} bar
|
|
|
|
r get foo{t}
|
|
|
|
r set foo2{t} bar2
|
|
|
|
r get foo2{t}
|
|
|
|
r set foo3{t} bar3
|
|
|
|
r get foo3{t}
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{multi}
|
Fix replication inconsistency on modules that uses key space notifications (#10969)
Fix replication inconsistency on modules that uses key space notifications.
### The Problem
In general, key space notifications are invoked after the command logic was
executed (this is not always the case, we will discuss later about specific
command that do not follow this rules). For example, the `set x 1` will trigger
a `set` notification that will be invoked after the `set` logic was performed, so
if the notification logic will try to fetch `x`, it will see the new data that was written.
Consider the scenario on which the notification logic performs some write
commands. for example, the notification logic increase some counter,
`incr x{counter}`, indicating how many times `x` was changed.
The logical order by which the logic was executed is has follow:
```
set x 1
incr x{counter}
```
The issue is that the `set x 1` command is added to the replication buffer
at the end of the command invocation (specifically after the key space
notification logic was invoked and performed the `incr` command).
The replication/aof sees the commands in the wrong order:
```
incr x{counter}
set x 1
```
In this specific example the order is less important.
But if, for example, the notification would have deleted `x` then we would
end up with primary-replica inconsistency.
### The Solution
Put the command that cause the notification in its rightful place. In the
above example, the `set x 1` command logic was executed before the
notification logic, so it should be added to the replication buffer before
the commands that is invoked by the notification logic. To achieve this,
without a major code refactoring, we save a placeholder in the replication
buffer, when finishing invoking the command logic we check if the command
need to be replicated, and if it does, we use the placeholder to add it to the
replication buffer instead of appending it to the end.
To be efficient and not allocating memory on each command to save the
placeholder, the replication buffer array was modified to reuse memory
(instead of allocating it each time we want to replicate commands).
Also, to avoid saving a placeholder when not needed, we do it only for
WRITE or MAY_REPLICATE commands.
#### Additional Fixes
* Expire and Eviction notifications:
* Expire/Eviction logical order was to first perform the Expire/Eviction
and then the notification logic. The replication buffer got this in the
other way around (first notification effect and then the `del` command).
The PR fixes this issue.
* The notification effect and the `del` command was not wrap with
`multi-exec` (if needed). The PR also fix this issue.
* SPOP command:
* On spop, the `spop` notification was fired before the command logic
was executed. The change in this PR would have cause the replication
order to be change (first `spop` command and then notification `logic`)
although the logical order is first the notification logic and then the
`spop` logic. The right fix would have been to move the notification to
be fired after the command was executed (like all the other commands),
but this can be considered a breaking change. To overcome this, the PR
keeps the current behavior and changes the `spop` code to keep the right
logical order when pushing commands to the replication buffer. Another PR
will follow to fix the SPOP properly and match it to the other command (we
split it to 2 separate PR's so it will be easy to cherry-pick this PR to 7.0 if
we chose to).
#### Unhanded Known Limitations
* key miss event:
* On key miss event, if a module performed some write command on the
event (using `RM_Call`), the `dirty` counter would increase and the read
command that cause the key miss event would be replicated to the replication
and aof. This problem can also happened on a write command that open
some keys but eventually decides not to perform any action. We decided
not to handle this problem on this PR because the solution is complex
and will cause additional risks in case we will want to cherry-pick this PR.
We should decide if we want to handle it in future PR's. For now, modules
writers is advice not to perform any write commands on key miss event.
#### Testing
* We already have tests to cover cases where a notification is invoking write
commands that are also added to the replication buffer, the tests was modified
to verify that the replica gets the command in the correct logical order.
* Test was added to verify that `spop` behavior was kept unchanged.
* Test was added to verify key miss event behave as expected.
* Test was added to verify the changes do not break lazy expiration.
#### Additional Changes
* `propagateNow` function can accept a special dbid, -1, indicating not
to replicate `select`. We use this to replicate `multi/exec` on `propagatePendingCommands`
function. The side effect of this change is that now the `select` command
will appear inside the `multi/exec` block on the replication stream (instead of
outside of the `multi/exec` block). Tests was modified to match this new behavior.
2022-08-18 03:16:32 -04:00
|
|
|
{select *}
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
{set foo{t} bar}
|
|
|
|
{set foo2{t} bar2}
|
|
|
|
{set foo3{t} bar3}
|
2013-03-27 06:31:27 -04:00
|
|
|
{exec}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
2013-03-27 06:31:27 -04:00
|
|
|
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
test {MULTI / EXEC is propagated correctly (multiple commands with SELECT)} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r select 1
|
|
|
|
r set foo{t} bar
|
|
|
|
r get foo{t}
|
|
|
|
r select 2
|
|
|
|
r set foo2{t} bar2
|
|
|
|
r get foo2{t}
|
|
|
|
r select 3
|
|
|
|
r set foo3{t} bar3
|
|
|
|
r get foo3{t}
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{multi}
|
Fix replication inconsistency on modules that uses key space notifications (#10969)
Fix replication inconsistency on modules that uses key space notifications.
### The Problem
In general, key space notifications are invoked after the command logic was
executed (this is not always the case, we will discuss later about specific
command that do not follow this rules). For example, the `set x 1` will trigger
a `set` notification that will be invoked after the `set` logic was performed, so
if the notification logic will try to fetch `x`, it will see the new data that was written.
Consider the scenario on which the notification logic performs some write
commands. for example, the notification logic increase some counter,
`incr x{counter}`, indicating how many times `x` was changed.
The logical order by which the logic was executed is has follow:
```
set x 1
incr x{counter}
```
The issue is that the `set x 1` command is added to the replication buffer
at the end of the command invocation (specifically after the key space
notification logic was invoked and performed the `incr` command).
The replication/aof sees the commands in the wrong order:
```
incr x{counter}
set x 1
```
In this specific example the order is less important.
But if, for example, the notification would have deleted `x` then we would
end up with primary-replica inconsistency.
### The Solution
Put the command that cause the notification in its rightful place. In the
above example, the `set x 1` command logic was executed before the
notification logic, so it should be added to the replication buffer before
the commands that is invoked by the notification logic. To achieve this,
without a major code refactoring, we save a placeholder in the replication
buffer, when finishing invoking the command logic we check if the command
need to be replicated, and if it does, we use the placeholder to add it to the
replication buffer instead of appending it to the end.
To be efficient and not allocating memory on each command to save the
placeholder, the replication buffer array was modified to reuse memory
(instead of allocating it each time we want to replicate commands).
Also, to avoid saving a placeholder when not needed, we do it only for
WRITE or MAY_REPLICATE commands.
#### Additional Fixes
* Expire and Eviction notifications:
* Expire/Eviction logical order was to first perform the Expire/Eviction
and then the notification logic. The replication buffer got this in the
other way around (first notification effect and then the `del` command).
The PR fixes this issue.
* The notification effect and the `del` command was not wrap with
`multi-exec` (if needed). The PR also fix this issue.
* SPOP command:
* On spop, the `spop` notification was fired before the command logic
was executed. The change in this PR would have cause the replication
order to be change (first `spop` command and then notification `logic`)
although the logical order is first the notification logic and then the
`spop` logic. The right fix would have been to move the notification to
be fired after the command was executed (like all the other commands),
but this can be considered a breaking change. To overcome this, the PR
keeps the current behavior and changes the `spop` code to keep the right
logical order when pushing commands to the replication buffer. Another PR
will follow to fix the SPOP properly and match it to the other command (we
split it to 2 separate PR's so it will be easy to cherry-pick this PR to 7.0 if
we chose to).
#### Unhanded Known Limitations
* key miss event:
* On key miss event, if a module performed some write command on the
event (using `RM_Call`), the `dirty` counter would increase and the read
command that cause the key miss event would be replicated to the replication
and aof. This problem can also happened on a write command that open
some keys but eventually decides not to perform any action. We decided
not to handle this problem on this PR because the solution is complex
and will cause additional risks in case we will want to cherry-pick this PR.
We should decide if we want to handle it in future PR's. For now, modules
writers is advice not to perform any write commands on key miss event.
#### Testing
* We already have tests to cover cases where a notification is invoking write
commands that are also added to the replication buffer, the tests was modified
to verify that the replica gets the command in the correct logical order.
* Test was added to verify that `spop` behavior was kept unchanged.
* Test was added to verify key miss event behave as expected.
* Test was added to verify the changes do not break lazy expiration.
#### Additional Changes
* `propagateNow` function can accept a special dbid, -1, indicating not
to replicate `select`. We use this to replicate `multi/exec` on `propagatePendingCommands`
function. The side effect of this change is that now the `select` command
will appear inside the `multi/exec` block on the replication stream (instead of
outside of the `multi/exec` block). Tests was modified to match this new behavior.
2022-08-18 03:16:32 -04:00
|
|
|
{select *}
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
{set foo{t} bar}
|
|
|
|
{select *}
|
|
|
|
{set foo2{t} bar2}
|
|
|
|
{select *}
|
|
|
|
{set foo3{t} bar3}
|
|
|
|
{exec}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
|
|
|
} {} {needs:repl singledb:skip}
|
|
|
|
|
2013-03-27 06:31:27 -04:00
|
|
|
test {MULTI / EXEC is propagated correctly (empty transaction)} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r exec
|
|
|
|
r set foo bar
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{set foo bar}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
2013-03-27 06:31:27 -04:00
|
|
|
|
|
|
|
test {MULTI / EXEC is propagated correctly (read-only commands)} {
|
|
|
|
r set foo value1
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r get foo
|
|
|
|
r exec
|
|
|
|
r set foo value2
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{set foo value2}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
2013-03-27 06:31:27 -04:00
|
|
|
|
|
|
|
test {MULTI / EXEC is propagated correctly (write command, no effect)} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r del bar
|
|
|
|
r del foo
|
2013-03-27 06:31:27 -04:00
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r multi
|
|
|
|
r del foo
|
|
|
|
r exec
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
|
|
|
|
# add another command so that when we see it we know multi-exec wasn't
|
|
|
|
# propagated
|
|
|
|
r incr foo
|
|
|
|
|
2013-03-27 06:31:27 -04:00
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
{incr foo}
|
2013-03-27 06:31:27 -04:00
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
2019-09-21 13:58:57 -04:00
|
|
|
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
test {MULTI / EXEC with REPLICAOF} {
|
|
|
|
# This test verifies that if we demote a master to replica inside a transaction, the
|
|
|
|
# entire transaction is not propagated to the already-connected replica
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
r set foo bar
|
|
|
|
r multi
|
|
|
|
r set foo2 bar
|
|
|
|
r replicaof localhost 9999
|
|
|
|
r set foo3 bar
|
|
|
|
r exec
|
|
|
|
catch {r set foo4 bar} e
|
|
|
|
assert_match {READONLY*} $e
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{set foo bar}
|
|
|
|
}
|
|
|
|
r replicaof no one
|
|
|
|
} {OK} {needs:repl cluster:skip}
|
|
|
|
|
2019-09-21 13:58:57 -04:00
|
|
|
test {DISCARD should not fail during OOM} {
|
|
|
|
set rd [redis_deferring_client]
|
|
|
|
$rd config set maxmemory 1
|
|
|
|
assert {[$rd read] eq {OK}}
|
|
|
|
r multi
|
|
|
|
catch {r set x 1} e
|
|
|
|
assert_match {OOM*} $e
|
|
|
|
r discard
|
|
|
|
$rd config set maxmemory 0
|
|
|
|
assert {[$rd read] eq {OK}}
|
|
|
|
$rd close
|
|
|
|
r ping
|
2021-06-09 08:13:24 -04:00
|
|
|
} {PONG} {needs:config-maxmemory}
|
2020-03-23 14:13:52 -04:00
|
|
|
|
|
|
|
test {MULTI and script timeout} {
|
|
|
|
# check that if MULTI arrives during timeout, it is either refused, or
|
|
|
|
# allowed to pass, and we don't end up executing half of the transaction
|
|
|
|
set rd1 [redis_deferring_client]
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set r2 [redis_client]
|
2020-03-23 14:13:52 -04:00
|
|
|
r config set lua-time-limit 10
|
|
|
|
r set xx 1
|
|
|
|
$rd1 eval {while true do end} 0
|
|
|
|
after 200
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 multi; } e
|
|
|
|
catch { $r2 incr xx; } e
|
2020-03-23 14:13:52 -04:00
|
|
|
r script kill
|
|
|
|
after 200 ; # Give some time to Lua to call the hook again...
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 incr xx; } e
|
|
|
|
catch { $r2 exec; } e
|
|
|
|
assert_match {EXECABORT*previous errors*} $e
|
2020-03-23 14:13:52 -04:00
|
|
|
set xx [r get xx]
|
|
|
|
# make sure that either the whole transcation passed or none of it (we actually expect none)
|
|
|
|
assert { $xx == 1 || $xx == 3}
|
|
|
|
# check that the connection is no longer in multi state
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set pong [$r2 ping asdf]
|
2020-03-23 14:13:52 -04:00
|
|
|
assert_equal $pong "asdf"
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
$rd1 close; $r2 close
|
2020-03-23 14:13:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
test {EXEC and script timeout} {
|
|
|
|
# check that if EXEC arrives during timeout, we don't end up executing
|
|
|
|
# half of the transaction, and also that we exit the multi state
|
|
|
|
set rd1 [redis_deferring_client]
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set r2 [redis_client]
|
2020-03-23 14:13:52 -04:00
|
|
|
r config set lua-time-limit 10
|
|
|
|
r set xx 1
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 multi; } e
|
|
|
|
catch { $r2 incr xx; } e
|
2020-03-23 14:13:52 -04:00
|
|
|
$rd1 eval {while true do end} 0
|
|
|
|
after 200
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 incr xx; } e
|
|
|
|
catch { $r2 exec; } e
|
|
|
|
assert_match {EXECABORT*BUSY*} $e
|
2020-03-23 14:13:52 -04:00
|
|
|
r script kill
|
|
|
|
after 200 ; # Give some time to Lua to call the hook again...
|
|
|
|
set xx [r get xx]
|
|
|
|
# make sure that either the whole transcation passed or none of it (we actually expect none)
|
|
|
|
assert { $xx == 1 || $xx == 3}
|
|
|
|
# check that the connection is no longer in multi state
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set pong [$r2 ping asdf]
|
2020-03-23 14:13:52 -04:00
|
|
|
assert_equal $pong "asdf"
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
$rd1 close; $r2 close
|
2020-03-23 14:13:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
test {MULTI-EXEC body and script timeout} {
|
2021-06-10 08:39:33 -04:00
|
|
|
# check that we don't run an incomplete transaction due to some commands
|
2020-03-23 14:13:52 -04:00
|
|
|
# arriving during busy script
|
|
|
|
set rd1 [redis_deferring_client]
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set r2 [redis_client]
|
2020-03-23 14:13:52 -04:00
|
|
|
r config set lua-time-limit 10
|
|
|
|
r set xx 1
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 multi; } e
|
|
|
|
catch { $r2 incr xx; } e
|
2020-03-23 14:13:52 -04:00
|
|
|
$rd1 eval {while true do end} 0
|
|
|
|
after 200
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 incr xx; } e
|
2020-03-23 14:13:52 -04:00
|
|
|
r script kill
|
|
|
|
after 200 ; # Give some time to Lua to call the hook again...
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
catch { $r2 exec; } e
|
|
|
|
assert_match {EXECABORT*previous errors*} $e
|
2020-03-23 14:13:52 -04:00
|
|
|
set xx [r get xx]
|
|
|
|
# make sure that either the whole transcation passed or none of it (we actually expect none)
|
|
|
|
assert { $xx == 1 || $xx == 3}
|
|
|
|
# check that the connection is no longer in multi state
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
set pong [$r2 ping asdf]
|
2020-03-23 14:13:52 -04:00
|
|
|
assert_equal $pong "asdf"
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
$rd1 close; $r2 close
|
|
|
|
}
|
|
|
|
|
|
|
|
test {just EXEC and script timeout} {
|
|
|
|
# check that if EXEC arrives during timeout, we don't end up executing
|
|
|
|
# actual commands during busy script, and also that we exit the multi state
|
|
|
|
set rd1 [redis_deferring_client]
|
|
|
|
set r2 [redis_client]
|
|
|
|
r config set lua-time-limit 10
|
|
|
|
r set xx 1
|
|
|
|
catch { $r2 multi; } e
|
|
|
|
catch { $r2 incr xx; } e
|
|
|
|
$rd1 eval {while true do end} 0
|
|
|
|
after 200
|
|
|
|
catch { $r2 exec; } e
|
|
|
|
assert_match {EXECABORT*BUSY*} $e
|
|
|
|
r script kill
|
|
|
|
after 200 ; # Give some time to Lua to call the hook again...
|
|
|
|
set xx [r get xx]
|
|
|
|
# make we didn't execute the transaction
|
|
|
|
assert { $xx == 1}
|
|
|
|
# check that the connection is no longer in multi state
|
|
|
|
set pong [$r2 ping asdf]
|
|
|
|
assert_equal $pong "asdf"
|
|
|
|
$rd1 close; $r2 close
|
|
|
|
}
|
|
|
|
|
|
|
|
test {exec with write commands and state change} {
|
|
|
|
# check that exec that contains write commands fails if server state changed since they were queued
|
|
|
|
set r1 [redis_client]
|
|
|
|
r set xx 1
|
|
|
|
r multi
|
|
|
|
r incr xx
|
|
|
|
$r1 config set min-replicas-to-write 2
|
|
|
|
catch {r exec} e
|
|
|
|
assert_match {*EXECABORT*NOREPLICAS*} $e
|
|
|
|
set xx [r get xx]
|
|
|
|
# make sure that the INCR wasn't executed
|
|
|
|
assert { $xx == 1}
|
|
|
|
$r1 config set min-replicas-to-write 0
|
2021-06-09 08:13:24 -04:00
|
|
|
$r1 close
|
|
|
|
} {0} {needs:repl}
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
|
|
|
|
test {exec with read commands and stale replica state change} {
|
|
|
|
# check that exec that contains read commands fails if server state changed since they were queued
|
|
|
|
r config set replica-serve-stale-data no
|
|
|
|
set r1 [redis_client]
|
|
|
|
r set xx 1
|
|
|
|
|
2021-11-18 03:53:17 -05:00
|
|
|
# check that GET and PING are disallowed on stale replica, even if the replica becomes stale only after queuing.
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
r multi
|
|
|
|
r get xx
|
|
|
|
$r1 replicaof localhsot 0
|
|
|
|
catch {r exec} e
|
|
|
|
assert_match {*EXECABORT*MASTERDOWN*} $e
|
|
|
|
|
2021-11-18 03:53:17 -05:00
|
|
|
# reset
|
|
|
|
$r1 replicaof no one
|
|
|
|
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
r multi
|
|
|
|
r ping
|
|
|
|
$r1 replicaof localhsot 0
|
2021-11-18 03:53:17 -05:00
|
|
|
catch {r exec} e
|
|
|
|
assert_match {*EXECABORT*MASTERDOWN*} $e
|
EXEC always fails with EXECABORT and multi-state is cleared
In order to support the use of multi-exec in pipeline, it is important that
MULTI and EXEC are never rejected and it is easy for the client to know if the
connection is still in multi state.
It was easy to make sure MULTI and DISCARD never fail (done by previous
commits) since these only change the client state and don't do any actual
change in the server, but EXEC is a different story.
Since in the past, it was possible for clients to handle some EXEC errors and
retry the EXEC, we now can't affort to return any error on EXEC other than
EXECABORT, which now carries with it the real reason for the abort too.
Other fixes in this commit:
- Some checks that where performed at the time of queuing need to be re-
validated when EXEC runs, for instance if the transaction contains writes
commands, it needs to be aborted. there was one check that was already done
in execCommand (-READONLY), but other checks where missing: -OOM, -MISCONF,
-NOREPLICAS, -MASTERDOWN
- When a command is rejected by processCommand it was rejected with addReply,
which was not recognized as an error in case the bad command came from the
master. this will enable to count or MONITOR these errors in the future.
- make it easier for tests to create additional (non deferred) clients.
- add tests for the fixes of this commit.
2020-06-11 14:09:35 -04:00
|
|
|
|
|
|
|
# check that when replica is not stale, GET is allowed
|
|
|
|
# while we're at it, let's check that multi is allowed on stale replica too
|
|
|
|
r multi
|
|
|
|
$r1 replicaof no one
|
|
|
|
r get xx
|
|
|
|
set xx [r exec]
|
|
|
|
# make sure that the INCR was executed
|
|
|
|
assert { $xx == 1 }
|
2021-06-09 08:13:24 -04:00
|
|
|
$r1 close
|
|
|
|
} {0} {needs:repl cluster:skip}
|
2020-08-27 02:19:24 -04:00
|
|
|
|
|
|
|
test {EXEC with only read commands should not be rejected when OOM} {
|
|
|
|
set r2 [redis_client]
|
|
|
|
|
|
|
|
r set x value
|
|
|
|
r multi
|
|
|
|
r get x
|
|
|
|
r ping
|
|
|
|
|
|
|
|
# enforcing OOM
|
|
|
|
$r2 config set maxmemory 1
|
|
|
|
|
|
|
|
# finish the multi transaction with exec
|
|
|
|
assert { [r exec] == {value PONG} }
|
|
|
|
|
|
|
|
# releasing OOM
|
|
|
|
$r2 config set maxmemory 0
|
|
|
|
$r2 close
|
2021-06-09 08:13:24 -04:00
|
|
|
} {0} {needs:config-maxmemory}
|
2020-08-27 02:19:24 -04:00
|
|
|
|
|
|
|
test {EXEC with at least one use-memory command should fail} {
|
|
|
|
set r2 [redis_client]
|
|
|
|
|
|
|
|
r multi
|
|
|
|
r set x 1
|
|
|
|
r get x
|
|
|
|
|
|
|
|
# enforcing OOM
|
|
|
|
$r2 config set maxmemory 1
|
|
|
|
|
|
|
|
# finish the multi transaction with exec
|
|
|
|
catch {r exec} e
|
|
|
|
assert_match {EXECABORT*OOM*} $e
|
|
|
|
|
|
|
|
# releasing OOM
|
|
|
|
$r2 config set maxmemory 0
|
|
|
|
$r2 close
|
2021-06-09 08:13:24 -04:00
|
|
|
} {0} {needs:config-maxmemory}
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 11:58:55 -05:00
|
|
|
|
|
|
|
test {Blocking commands ignores the timeout} {
|
2021-06-09 08:13:24 -04:00
|
|
|
r xgroup create s{t} g $ MKSTREAM
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 11:58:55 -05:00
|
|
|
|
|
|
|
set m [r multi]
|
2021-06-09 08:13:24 -04:00
|
|
|
r blpop empty_list{t} 0
|
|
|
|
r brpop empty_list{t} 0
|
|
|
|
r brpoplpush empty_list1{t} empty_list2{t} 0
|
|
|
|
r blmove empty_list1{t} empty_list2{t} LEFT LEFT 0
|
|
|
|
r bzpopmin empty_zset{t} 0
|
|
|
|
r bzpopmax empty_zset{t} 0
|
|
|
|
r xread BLOCK 0 STREAMS s{t} $
|
|
|
|
r xreadgroup group g c BLOCK 0 STREAMS s{t} >
|
Unified MULTI, LUA, and RM_Call with respect to blocking commands (#8025)
Blocking command should not be used with MULTI, LUA, and RM_Call. This is because,
the caller, who executes the command in this context, expects a reply.
Today, LUA and MULTI have a special (and different) treatment to blocking commands:
LUA - Most commands are marked with no-script flag which are checked when executing
and command from LUA, commands that are not marked (like XREAD) verify that their
blocking mode is not used inside LUA (by checking the CLIENT_LUA client flag).
MULTI - Command that is going to block, first verify that the client is not inside
multi (by checking the CLIENT_MULTI client flag). If the client is inside multi, they
return a result which is a match to the empty key with no timeout (for example blpop
inside MULTI will act as lpop)
For modules that perform RM_Call with blocking command, the returned results type is
REDISMODULE_REPLY_UNKNOWN and the caller can not really know what happened.
Disadvantages of the current state are:
No unified approach, LUA, MULTI, and RM_Call, each has a different treatment
Module can not safely execute blocking command (and get reply or error).
Though It is true that modules are not like LUA or MULTI and should be smarter not
to execute blocking commands on RM_Call, sometimes you want to execute a command base
on client input (for example if you create a module that provides a new scripting
language like javascript or python).
While modules (on modules command) can check for REDISMODULE_CTX_FLAGS_LUA or
REDISMODULE_CTX_FLAGS_MULTI to know not to block the client, there is no way to
check if the command came from another module using RM_Call. So there is no way
for a module to know not to block another module RM_Call execution.
This commit adds a way to unify the treatment for blocking clients by introducing
a new CLIENT_DENY_BLOCKING client flag. On LUA, MULTI, and RM_Call the new flag
turned on to signify that the client should not be blocked. A blocking command
verifies that the flag is turned off before blocking. If a blocking command sees
that the CLIENT_DENY_BLOCKING flag is on, it's not blocking and return results
which are matches to empty key with no timeout (as MULTI does today).
The new flag is checked on the following commands:
List blocking commands: BLPOP, BRPOP, BRPOPLPUSH, BLMOVE,
Zset blocking commands: BZPOPMIN, BZPOPMAX
Stream blocking commands: XREAD, XREADGROUP
SUBSCRIBE, PSUBSCRIBE, MONITOR
In addition, the new flag is turned on inside the AOF client, we do not want to
block the AOF client to prevent deadlocks and commands ordering issues (and there
is also an existing assert in the code that verifies it).
To keep backward compatibility on LUA, all the no-script flags on existing commands
were kept untouched. In addition, a LUA special treatment on XREAD and XREADGROUP was kept.
To keep backward compatibility on MULTI (which today allows SUBSCRIBE, and PSUBSCRIBE).
We added a special treatment on those commands to allow executing them on MULTI.
The only backward compatibility issue that this PR introduces is that now MONITOR
is not allowed inside MULTI.
Tests were added to verify blocking commands are not blocking the client on LUA, MULTI,
or RM_Call. Tests were added to verify the module can check for CLIENT_DENY_BLOCKING flag.
Co-authored-by: Oran Agra <oran@redislabs.com>
Co-authored-by: Itamar Haber <itamar@redislabs.com>
2020-11-17 11:58:55 -05:00
|
|
|
set res [r exec]
|
|
|
|
|
|
|
|
list $m $res
|
|
|
|
} {OK {{} {} {} {} {} {} {} {}}}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
|
|
|
|
test {MULTI propagation of PUBLISH} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
|
|
|
|
r multi
|
|
|
|
r publish bla bla
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{publish bla bla}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl cluster:skip}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
|
|
|
|
test {MULTI propagation of SCRIPT LOAD} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
|
2021-12-21 01:32:42 -05:00
|
|
|
# make sure that SCRIPT LOAD inside MULTI isn't propagated
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
r multi
|
|
|
|
r script load {redis.call('set', KEYS[1], 'foo')}
|
2021-12-21 01:32:42 -05:00
|
|
|
r set foo bar
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
set res [r exec]
|
|
|
|
set sha [lindex $res 0]
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
2021-12-21 01:32:42 -05:00
|
|
|
{set foo bar}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
|
2021-12-21 01:32:42 -05:00
|
|
|
test {MULTI propagation of EVAL} {
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
|
2021-12-21 01:32:42 -05:00
|
|
|
# make sure that EVAL inside MULTI is propagated in a transaction in effects
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
r multi
|
|
|
|
r eval {redis.call('set', KEYS[1], 'bar')} 1 bar
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
2021-12-21 01:32:42 -05:00
|
|
|
{set bar bar}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
|
2021-12-21 01:32:42 -05:00
|
|
|
test {MULTI propagation of SCRIPT FLUSH} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
|
|
|
|
# make sure that SCRIPT FLUSH isn't propagated
|
|
|
|
r multi
|
|
|
|
r script flush
|
|
|
|
r set foo bar
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{set foo bar}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-12-28 09:23:02 -05:00
|
|
|
} {} {needs:repl}
|
2021-12-21 01:32:42 -05:00
|
|
|
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
tags {"stream"} {
|
|
|
|
test {MULTI propagation of XREADGROUP} {
|
|
|
|
set repl [attach_to_replication_stream]
|
|
|
|
|
|
|
|
r XADD mystream * foo bar
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
r XADD mystream * foo2 bar2
|
|
|
|
r XADD mystream * foo3 bar3
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
r XGROUP CREATE mystream mygroup 0
|
|
|
|
|
|
|
|
# make sure the XCALIM (propagated by XREADGROUP) is indeed inside MULTI/EXEC
|
|
|
|
r multi
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
r XREADGROUP GROUP mygroup consumer1 COUNT 2 STREAMS mystream ">"
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
r XREADGROUP GROUP mygroup consumer1 STREAMS mystream ">"
|
|
|
|
r exec
|
|
|
|
|
|
|
|
assert_replication_stream $repl {
|
|
|
|
{select *}
|
|
|
|
{xadd *}
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
{xadd *}
|
|
|
|
{xadd *}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
{xgroup CREATE *}
|
|
|
|
{multi}
|
|
|
|
{xclaim *}
|
Sort out mess around propagation and MULTI/EXEC (#9890)
The mess:
Some parts use alsoPropagate for late propagation, others using an immediate one (propagate()),
causing edge cases, ugly/hacky code, and the tendency for bugs
The basic idea is that all commands are propagated via alsoPropagate (i.e. added to a list) and the
top-most call() is responsible for going over that list and actually propagating them (and wrapping
them in MULTI/EXEC if there's more than one command). This is done in the new function,
propagatePendingCommands.
Callers to propagatePendingCommands:
1. top-most call() (we want all nested call()s to add to the also_propagate array and just the top-most
one to propagate them) - via `afterCommand`
2. handleClientsBlockedOnKeys: it is out of call() context and it may propagate stuff - via `afterCommand`.
3. handleClientsBlockedOnKeys edge case: if the looked-up key is already expired, we will propagate the
expire but will not unblock any client so `afterCommand` isn't called. in that case, we have to propagate
the deletion explicitly.
4. cron stuff: active-expire and eviction may also propagate stuff
5. modules: the module API allows to propagate stuff from just about anywhere (timers, keyspace notifications,
threads). I could have tried to catch all the out-of-call-context places but it seemed easier to handle it in one
place: when we free the context. in the spirit of what was done in call(), only the top-most freeing of a module
context may cause propagation.
6. modules: when using a thread-safe ctx it's not clear when/if the ctx will be freed. we do know that the module
must lock the GIL before calling RM_Replicate/RM_Call so we propagate the pending commands when
releasing the GIL.
A "known limitation", which were actually a bug, was fixed because of this commit (see propagate.tcl):
When using a mix of RM_Call with `!` and RM_Replicate, the command would propagate out-of-order:
first all the commands from RM_Call, and then the ones from RM_Replicate
Another thing worth mentioning is that if, in the past, a client would issue a MULTI/EXEC with just one
write command the server would blindly propagate the MULTI/EXEC too, even though it's redundant.
not anymore.
This commit renames propagate() to propagateNow() in order to cause conflicts in pending PRs.
propagatePendingCommands is the only caller of propagateNow, which is now a static, internal helper function.
Optimizations:
1. alsoPropagate will not add stuff to also_propagate if there's no AOF and replicas
2. alsoPropagate reallocs also_propagagte exponentially, to save calls to memmove
Bugfixes:
1. CONFIG SET can create evictions, sending notifications which can cause to dirty++ with modules.
we need to prevent it from propagating to AOF/replicas
2. We need to set current_client in RM_Call. buggy scenario:
- CONFIG SET maxmemory, eviction notifications, module hook calls RM_Call
- assertion in lookupKey crashes, because current_client has CONFIG SET, which isn't CMD_WRITE
3. minor: in eviction, call propagateDeletion after notification, like active-expire and all commands
(we always send a notification before propagating the command)
2021-12-22 17:03:48 -05:00
|
|
|
{xclaim *}
|
|
|
|
{xclaim *}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
{exec}
|
|
|
|
}
|
|
|
|
close_replication_stream $repl
|
2021-06-09 08:13:24 -04:00
|
|
|
} {} {needs:repl}
|
Remove read-only flag from non-keyspace cmds, different approach for EXEC to propagate MULTI (#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.
2020-12-22 05:03:49 -05:00
|
|
|
}
|
|
|
|
|
2022-01-04 06:37:47 -05:00
|
|
|
foreach {cmd} {SAVE SHUTDOWN} {
|
|
|
|
test "MULTI with $cmd" {
|
|
|
|
r del foo
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
catch {r $cmd} e1
|
|
|
|
catch {r exec} e2
|
|
|
|
assert_match {*Command not allowed inside a transaction*} $e1
|
|
|
|
assert_match {EXECABORT*} $e2
|
|
|
|
r get foo
|
|
|
|
} {}
|
|
|
|
}
|
|
|
|
|
|
|
|
test "MULTI with BGREWRITEAOF" {
|
|
|
|
set forks [s total_forks]
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
r BGREWRITEAOF
|
|
|
|
set res [r exec]
|
|
|
|
assert_match "*rewriting scheduled*" [lindex $res 1]
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[s total_forks] > $forks
|
|
|
|
} else {
|
|
|
|
fail "aofrw didn't start"
|
|
|
|
}
|
|
|
|
waitForBgrewriteaof r
|
|
|
|
} {} {external:skip}
|
|
|
|
|
|
|
|
test "MULTI with config set appendonly" {
|
|
|
|
set lines [count_log_lines 0]
|
|
|
|
set forks [s total_forks]
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
r config set appendonly yes
|
|
|
|
r exec
|
|
|
|
verify_log_message 0 "*AOF background was scheduled*" $lines
|
|
|
|
wait_for_condition 50 100 {
|
|
|
|
[s total_forks] > $forks
|
|
|
|
} else {
|
|
|
|
fail "aofrw didn't start"
|
|
|
|
}
|
|
|
|
waitForBgrewriteaof r
|
|
|
|
} {} {external:skip}
|
|
|
|
|
|
|
|
test "MULTI with config error" {
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
r config set maxmemory bla
|
|
|
|
|
|
|
|
# letting the redis parser read it, it'll throw an exception instead of
|
|
|
|
# reply with an array that contains an error, so we switch to reading
|
|
|
|
# raw RESP instead
|
|
|
|
r readraw 1
|
|
|
|
|
|
|
|
set res [r exec]
|
|
|
|
assert_equal $res "*2"
|
|
|
|
set res [r read]
|
|
|
|
assert_equal $res "+OK"
|
|
|
|
set res [r read]
|
2023-05-04 04:58:31 -04:00
|
|
|
r readraw 0
|
2022-01-04 06:37:47 -05:00
|
|
|
set _ $res
|
|
|
|
} {*CONFIG SET failed*}
|
2023-02-28 05:02:55 -05:00
|
|
|
|
|
|
|
test "Flushall while watching several keys by one client" {
|
|
|
|
r flushall
|
2023-05-04 04:58:31 -04:00
|
|
|
r mset a{t} a b{t} b
|
|
|
|
r watch b{t} a{t}
|
2023-02-28 05:02:55 -05:00
|
|
|
r flushall
|
|
|
|
r ping
|
|
|
|
}
|
2022-01-04 06:37:47 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
start_server {overrides {appendonly {yes} appendfilename {appendonly.aof} appendfsync always} tags {external:skip}} {
|
|
|
|
test {MULTI with FLUSHALL and AOF} {
|
|
|
|
set aof [get_last_incr_aof_path r]
|
|
|
|
r multi
|
|
|
|
r set foo bar
|
|
|
|
r flushall
|
|
|
|
r exec
|
|
|
|
assert_aof_content $aof {
|
|
|
|
{multi}
|
Fix replication inconsistency on modules that uses key space notifications (#10969)
Fix replication inconsistency on modules that uses key space notifications.
### The Problem
In general, key space notifications are invoked after the command logic was
executed (this is not always the case, we will discuss later about specific
command that do not follow this rules). For example, the `set x 1` will trigger
a `set` notification that will be invoked after the `set` logic was performed, so
if the notification logic will try to fetch `x`, it will see the new data that was written.
Consider the scenario on which the notification logic performs some write
commands. for example, the notification logic increase some counter,
`incr x{counter}`, indicating how many times `x` was changed.
The logical order by which the logic was executed is has follow:
```
set x 1
incr x{counter}
```
The issue is that the `set x 1` command is added to the replication buffer
at the end of the command invocation (specifically after the key space
notification logic was invoked and performed the `incr` command).
The replication/aof sees the commands in the wrong order:
```
incr x{counter}
set x 1
```
In this specific example the order is less important.
But if, for example, the notification would have deleted `x` then we would
end up with primary-replica inconsistency.
### The Solution
Put the command that cause the notification in its rightful place. In the
above example, the `set x 1` command logic was executed before the
notification logic, so it should be added to the replication buffer before
the commands that is invoked by the notification logic. To achieve this,
without a major code refactoring, we save a placeholder in the replication
buffer, when finishing invoking the command logic we check if the command
need to be replicated, and if it does, we use the placeholder to add it to the
replication buffer instead of appending it to the end.
To be efficient and not allocating memory on each command to save the
placeholder, the replication buffer array was modified to reuse memory
(instead of allocating it each time we want to replicate commands).
Also, to avoid saving a placeholder when not needed, we do it only for
WRITE or MAY_REPLICATE commands.
#### Additional Fixes
* Expire and Eviction notifications:
* Expire/Eviction logical order was to first perform the Expire/Eviction
and then the notification logic. The replication buffer got this in the
other way around (first notification effect and then the `del` command).
The PR fixes this issue.
* The notification effect and the `del` command was not wrap with
`multi-exec` (if needed). The PR also fix this issue.
* SPOP command:
* On spop, the `spop` notification was fired before the command logic
was executed. The change in this PR would have cause the replication
order to be change (first `spop` command and then notification `logic`)
although the logical order is first the notification logic and then the
`spop` logic. The right fix would have been to move the notification to
be fired after the command was executed (like all the other commands),
but this can be considered a breaking change. To overcome this, the PR
keeps the current behavior and changes the `spop` code to keep the right
logical order when pushing commands to the replication buffer. Another PR
will follow to fix the SPOP properly and match it to the other command (we
split it to 2 separate PR's so it will be easy to cherry-pick this PR to 7.0 if
we chose to).
#### Unhanded Known Limitations
* key miss event:
* On key miss event, if a module performed some write command on the
event (using `RM_Call`), the `dirty` counter would increase and the read
command that cause the key miss event would be replicated to the replication
and aof. This problem can also happened on a write command that open
some keys but eventually decides not to perform any action. We decided
not to handle this problem on this PR because the solution is complex
and will cause additional risks in case we will want to cherry-pick this PR.
We should decide if we want to handle it in future PR's. For now, modules
writers is advice not to perform any write commands on key miss event.
#### Testing
* We already have tests to cover cases where a notification is invoking write
commands that are also added to the replication buffer, the tests was modified
to verify that the replica gets the command in the correct logical order.
* Test was added to verify that `spop` behavior was kept unchanged.
* Test was added to verify key miss event behave as expected.
* Test was added to verify the changes do not break lazy expiration.
#### Additional Changes
* `propagateNow` function can accept a special dbid, -1, indicating not
to replicate `select`. We use this to replicate `multi/exec` on `propagatePendingCommands`
function. The side effect of this change is that now the `select` command
will appear inside the `multi/exec` block on the replication stream (instead of
outside of the `multi/exec` block). Tests was modified to match this new behavior.
2022-08-18 03:16:32 -04:00
|
|
|
{select *}
|
2022-01-04 06:37:47 -05:00
|
|
|
{set *}
|
|
|
|
{flushall}
|
|
|
|
{exec}
|
|
|
|
}
|
|
|
|
r get foo
|
|
|
|
} {}
|
2010-05-25 08:04:46 -04:00
|
|
|
}
|