- 05 Mar, 2020 1 commit
-
-
Leo Murillo authored
-
- 19 Nov, 2019 1 commit
-
-
antirez authored
-
- 06 Nov, 2019 3 commits
-
-
antirez authored
One problem with the solution proposed so far in #6537 is that key lookups outside a command execution via call(), still used a cached time. The cached time needed to be refreshed in multiple places, especially because of modules callbacks from timers, cluster bus, and thread safe contexts, that may use RM_Open(). In order to avoid this problem, this commit introduces the ability to detect if we are inside call(): this way we can use the reference fixed time only when we are in the context of a command execution or Lua script, but for the asynchronous lookups, we can still use mstime() to get a fresh time reference.
-
antirez authored
After the thread in #6537 and thanks to the suggestions received, this commit updates the original patch in order to: 1. Solve the problem of updating the time in multiple places by updating it in call(). 2. Avoid introducing a new field but use our cached time. This required some minor refactoring to the function updating the time, and the introduction of a new cached time in microseconds in order to use less gettimeofday() calls.
-
zhaozhao.zz authored
Calling lookupKey*() many times to search a key in one command may get different result. That's because lookupKey*() calls expireIfNeeded(), and delete the key when reach the expire time. So we can get an robj before the expire time, but a NULL after the expire time. The worst is that may lead to Redis crash, for example `RPOPLPUSH foo foo` the first time we get a list form `foo` and hold the pointer, but when we get `foo` again it's expired and deleted. Now we hold a freed memory, when execute rpoplpushHandlePush() redis crash. To fix it, we can refactor the judgment about whether a key is expired, using the same basetime `server.cmd_start_mstime` instead of calling mstime() everytime.
-
- 11 Dec, 2018 1 commit
-
-
lsytj0413 authored
-
- 05 Nov, 2018 3 commits
-
-
zhaozhao.zz authored
-
antirez authored
-
zhaozhao.zz authored
-
- 02 Aug, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 30 Jul, 2018 3 commits
-
-
antirez authored
Related to #4852.
-
antirez authored
-
zhaozhao.zz authored
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 28 Jun, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 21 Jun, 2018 1 commit
-
-
shenlongxing authored
-
- 18 Jun, 2018 2 commits
-
-
antirez authored
The old version could not handle the fact that "STREAMS" is a valid key name for streams. Now we really try to parse the command like the command implementation would do. Related to #5028 and 4857.
-
antirez authored
The loop allocated a buffer for the right number of keys positions, then overflowed it going past the limit. Related to #4857 and cause of the memory violation seen in #5028.
-
- 14 Jun, 2018 1 commit
-
-
antirez authored
Thanks to @kevinmcgehee for signaling the issue and reasoning about the consequences and potential fixes. Issue #5015.
-
- 13 Jun, 2018 2 commits
-
-
zhaozhao.zz authored
-
antirez authored
Since the introduction of ZPOP makes this needed. Thanks to @oranagra for reporting.
-
- 12 Jun, 2018 1 commit
-
-
antirez authored
Since the introduction of ZPOP makes this needed. Thanks to @oranagra for reporting.
-
- 04 Jun, 2018 1 commit
-
-
赵磊 authored
-
- 29 Apr, 2018 1 commit
-
-
Itamar Haber authored
An implementation of the [Ze POP Redis Module](https://github.com/itamarhaber/zpop) as core Redis commands. Fixes #1861.
-
- 27 Feb, 2018 2 commits
- 11 Feb, 2018 1 commit
-
-
赵磊 authored
-
- 12 Jan, 2018 1 commit
-
-
antirez authored
This fixes a crash with Redis Cluster when OBJECT is mis-used, because getKeysUsingCommandTable() will call serverPanic() detecting we are accessing an invalid argument in the case "OBJECT foo" is called. This bug was introduced when OBJECT HELP was introduced, because the key argument is set fixed at index 2 in the command table, however now OBJECT may be called with an insufficient number of arguments to extract the key. The "Right Thing" would be to have a specific function to extract keys from the OBJECT command, however this is kinda of an overkill, so I preferred to make getKeysUsingCommandTable() more robust and just return no keys when it's not possible to honor the command table, because new commands are often added and also there are a number with an HELP subcommand violating the normal form, and crashing for this trivial reason or having many command-specific key extraction functions is not great.
-
- 01 Dec, 2017 5 commits
-
-
antirez authored
-
antirez authored
With lists we need to signal only on key creation, but streams can provide data to clients listening at every new item added. To make this slightly more efficient we now track different classes of blocked clients to avoid signaling keys when there is nobody listening. A typical case is when the stream is used as a time series DB and accessed only by range with XRANGE.
-
antirez authored
-
antirez authored
-
antirez authored
-
- 27 Nov, 2017 1 commit
-
-
zhaozhao.zz authored
Firstly, use access time to replace the decreas time of LFU. For function LFUDecrAndReturn, it should only try to get decremented counter, not update LFU fields, we will update it in an explicit way. And we will times halve the counter according to the times of elapsed time than server.lfu_decay_time. Everytime a key is accessed, we should update the LFU including update access time, and increment the counter after call function LFUDecrAndReturn. If a key is overwritten, the LFU should be also updated. Then we can use `OBJECT freq` command to get a key's frequence, and LFUDecrAndReturn should be called in `OBJECT freq` command in case of the key has not been accessed for a long time, because we update the access time only when the key is read or overwritten.
-
- 20 Sep, 2017 1 commit
-
-
zhaozhao.zz authored
This commit is a reinforcement of commit c1c99e9f. 1. Replication information can be stored when the RDB file is generated by a mater using server.slaveseldb when server.repl_backlog is not NULL, or set repl_stream_db be -1. That's safe, because NULL server.repl_backlog will trigger full synchronization, then master will send SELECT command to replicaiton stream. 2. Only do rdbSave* when rsiptr is not NULL, if we do rdbSave* without rdbSaveInfo, slave will miss repl-stream-db. 3. Save the replication informations also in the case of SAVE command, FLUSHALL command and DEBUG reload.
-
- 14 Jun, 2017 1 commit
-
-
Qu Chen authored
commands.
-
- 13 Jun, 2017 1 commit
-
-
antirez authored
-
- 19 Apr, 2017 1 commit
-
-
antirez authored
Close #3940.
-
- 07 Apr, 2017 1 commit
-
-
antirez authored
-
- 27 Mar, 2017 1 commit
-
-
antirez authored
-