diff options
| author | zhaozhao.zz <zhaozhao.zz@alibaba-inc.com> | 2019-01-15 16:58:29 +0800 |
|---|---|---|
| committer | zhaozhao.zz <zhaozhao.zz@alibaba-inc.com> | 2019-11-22 11:51:18 +0800 |
| commit | 097c4a65367d9d7c9cdfffe42c2103f3e64937fd (patch) | |
| tree | 5fcc5f4a4ce582da1a21c9417f7a98107406f739 | |
| parent | b93945585a74ab1c2e399447fad4cfe379ed8d25 (diff) | |
| download | redis-097c4a65367d9d7c9cdfffe42c2103f3e64937fd.tar.gz | |
scripting: flag lua_client as CLIENT_MULTI after redis.replicate_commands() immediately
To avoid nested MULTI/EXEC, we check the lua_caller's flag,
if we are in the MULTI context we flag the lua_client as
CLIENT_MULTI, but it's not enough we shoud flag lua_client
as CLIENT_MULTI after redis.replicate_commands() immediately
or the first write command after redis.replicate_commands()
cannot know it's in an transaction, I know the missing CLIENT_MULTI
doesn't have any effect now, but it's a real bug and we should fix
it, in case someday we allow some dangerous command like BLPOP.
| -rw-r--r-- | src/scripting.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/src/scripting.c b/src/scripting.c index 7cf21f408..76885a02b 100644 --- a/src/scripting.c +++ b/src/scripting.c @@ -703,6 +703,9 @@ int luaRedisGenericCommand(lua_State *lua, int raise_error) { { execCommandPropagateMulti(server.lua_caller); server.lua_multi_emitted = 1; + /* Now we are in the MULTI context, the lua_client should be + * flag as CLIENT_MULTI. */ + c->flags |= CLIENT_MULTI; } /* Run the command */ |