MOVE now can move TTL metadata as well.

MOVE was not able to move the TTL: when a key was moved into a different
database number, it became persistent like if PERSIST was used.

In some incredible way (I guess almost nobody uses Redis MOVE) this bug
remained unnoticed inside Redis internals for many years.
Finally Andy Grunwald discovered it and opened an issue.

This commit fixes the bug and adds a regression test.

Close #2765.
This commit is contained in:
antirez 2015-09-14 12:28:22 +02:00
parent 33769f840c
commit f529a01c1b
2 changed files with 16 additions and 1 deletions

View File

@ -743,7 +743,7 @@ void moveCommand(client *c) {
robj *o;
redisDb *src, *dst;
int srcid;
long long dbid;
long long dbid, expire;
if (server.cluster_enabled) {
addReplyError(c,"MOVE is not allowed in cluster mode");
@ -777,6 +777,7 @@ void moveCommand(client *c) {
addReply(c,shared.czero);
return;
}
expire = getExpire(c->db,c->argv[1]);
/* Return zero if the key already exists in the target DB */
if (lookupKeyWrite(dst,c->argv[1]) != NULL) {
@ -784,6 +785,7 @@ void moveCommand(client *c) {
return;
}
dbAdd(dst,c->argv[1],o);
if (expire) setExpire(dst,c->argv[1],expire);
incrRefCount(o);
/* OK! key moved, free the entry in the source DB */

View File

@ -193,6 +193,19 @@ start_server {tags {"keyspace"}} {
set e
} {*ERR*index out of range}
test {MOVE can move key expire metadata as well} {
r select 10
r flushdb
r select 9
r set mykey foo ex 100
r move mykey 10
assert {[r ttl mykey] == -2}
r select 10
assert {[r ttl mykey] > 0 && [r ttl mykey] <= 100}
assert {[r get mykey] eq "foo"}
r select 9
}
test {SET/GET keys in different DBs} {
r set a hello
r set b world