Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

SORT STORE on cluster works when it shouldn't #1580

Closed
mgravell opened this Issue · 3 comments

3 participants

@mgravell

SORT STORE is a multi-key command, so it probably shouldn't even work at all until beta 2, but more alarmingly: it works even when the target key is not on the server, for example - here "b" and "c" are on different nodes (as demonstrated in the first few lines).

Also, the "by" clause is also multi-key, so probably needs consideration.

flushdb
OK
get b
(nil)
get c
(error) MOVED ...
lpush b x
(integer) 1
lpush b y
(integer) 2
lpush b z
(integer) 3
sort b alpha
1) "x"
2) "y"
3) "z"
sort b alpha store c
(integer 3)
keys c
1) "c"
get c
(error) MOVED ...

Which shows that we've successfully put the database into an inconsistent state

@antirez antirez added this to the Redis 3.0 milestone
@mattsta

The sort command currently doesn't have a way of returning the key used in the store subcommand. We need to implement a custom getkeys_proc function to enumerate the optional store key.

@antirez
Owner

Yep... I'm fixing it today, however this means that I'll deny the "GET" option in SORT while in Cluster mode since we can't anticipate keys fetched, at least for now. It is actually possible to analyze the GET pattern and deny it only if it does not include an hash tag inside, then in the key extraction function return the pattern so that an error will be raised if it is not in the right hash slot.

@antirez
Owner

Fixed

@antirez antirez closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.