- 10 Jun, 2020 27 commits
-
-
antirez authored
Certain Redis objects may change upon read only access. This is the case, for instance, of hash tables, that may continue to incrementally rehash after a rehashing operation. A similar problem also happens with the PFCOUNT operation and other operations that may write as a side effect of reading. In the case of PFCOUNT probably the right approach would be to flag the command in a special way in the command table, so that the operation is blocked as it if was a write operation.
-
antirez authored
-
antirez authored
-
antirez authored
Moreover the sync mode was optimized to avoid creating a module context, blocking the client in the 'bc' handle and so forth. We already know this is going a synchronous execution (unlike in the case of failing to spawn a thread), so we can just call the callback.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 09 Jun, 2020 1 commit
-
-
antirez authored
-
- 08 Jun, 2020 3 commits
-
-
Oran Agra authored
the recent change in that loop (iteration rather than waiting for it to be empty) was intended to avoid an endless loop in case some slave would refuse to be freed. but the lookup of the first client remained, which would have caused it to try the first one again and again instead of moving on.
-
Oran Agra authored
-
Oran Agra authored
Much like MULTI/EXEC/DISCARD, the WATCH and UNWATCH are not actually operating on the database or server state, but instead operate on the client state. the client may send them all in one long pipeline and check all the responses only at the end, so failing them may lead to a mismatch between the client state on the server and the one on the client end, and execute the wrong commands (ones that were meant to be discarded) the watched keys are not actually stored in the client struct, but they are in fact part of the client state. for instance, they're not cleared or moved in SWAPDB or FLUSHDB.
-
- 07 Jun, 2020 1 commit
-
-
xhe authored
HELLO should return the current proto version, while the code hardcoded 3
-
- 06 Jun, 2020 2 commits
-
- 03 Jun, 2020 1 commit
-
-
zhaozhao.zz authored
-
- 02 Jun, 2020 1 commit
-
-
zhaozhao.zz authored
related #7234
-
- 29 May, 2020 1 commit
-
-
antirez authored
Now it is also possible for ACL SETUSER to accept empty strings as valid operations (doing nothing), so for instance ACL SETUSER myuser "" Will have just the effect of creating a user in the default state. This should fix #7329.
-
- 28 May, 2020 1 commit
-
-
antirez authored
-
- 27 May, 2020 2 commits