- 12 3月, 2020 3 次提交
-
-
由 antirez 提交于
-
由 Salvatore Sanfilippo 提交于
Fix Pi building needing -latomic, 5.0 branch backport
-
由 Dustin Collins 提交于
-
- 05 3月, 2020 18 次提交
-
-
由 srzhao 提交于
-
由 Ariel 提交于
-
由 Guy Benoish 提交于
Use built-in alsoPropagate mechanism that wraps commands in MULTI/EXEC before sending them to replica/AOF
-
由 Oran Agra 提交于
currently there's no bug since the flags these functions handle are always lower than 32bit, but still better fix the type to prevent future bugs.
-
由 Guy Benoish 提交于
1. server.repl_no_slaves_since can be set when a MONITOR client disconnects 2. c->repl_ack_time can be set by a newline from a MONITOR client 3. Improved comments
-
由 WuYunlong 提交于
-
由 antirez 提交于
-
由 WuYunlong 提交于
-
由 antirez 提交于
Related to #6054.
-
由 antirez 提交于
We exit later, so no bug fixed, but it is more correct. See #6054, thanks to @ShooterIT for finding the issue.
-
由 WuYunlong 提交于
-
由 WuYunlong 提交于
-
由 Leo Murillo 提交于
-
由 Guy Benoish 提交于
This commit solves the following bug: 127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM OK 127.0.0.1:6379> XADD x 666 f v "666-0" 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) 1) 1) "666-0" 2) 1) "f" 2) "v" 127.0.0.1:6379> XADD x 667 f v "667-0" 127.0.0.1:6379> XDEL x 667 (integer) 1 127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x > 1) 1) "x" 2) (empty array) The root cause is that we use s->last_id in streamCompareID while we should use the last *valid* ID
-
由 antirez 提交于
Fixes #6744.
-
由 Guy Benoish 提交于
This commit solves several edge cases that are related to exhausting the streamID limits: We should correctly calculate the succeeding streamID instead of blindly incrementing 'seq' This affects both XREAD and XADD. Other (unrelated) changes: Reply with a better error message when trying to add an entry to a stream that has exhausted last_id
-
由 antirez 提交于
-
由 antirez 提交于
This bug is from the first version of Redis. Probably the problem here is that before we used an SDS split function that created empty strings for additional spaces, like in "SET foo bar". AFAIK later we replaced it with the curretn sdssplitarg() API that has no such a problem. As a result, we introduced a bug, where it is no longer possible to do something like: SET foo "" Using the inline protocol. Now it is fixed.
-
- 12 2月, 2020 1 次提交
-
-
由 Khem Raj 提交于
This helps in avoiding multiple definition of this variable, its also defined globally in sds.c Signed-off-by: NKhem Raj <raj.khem@gmail.com>
-
- 10 2月, 2020 1 次提交
-
-
由 Seunghoon Woo 提交于
-
- 08 1月, 2020 1 次提交
-
-
由 yz1509 提交于
-
- 20 11月, 2019 16 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Oran Agra 提交于
It seeems that since I added the creation of the jemalloc thread redis sometimes fails to start with the following error: Inconsistency detected by ld.so: dl-tls.c: 493: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed! This seems to be due to a race bug in ld.so, in which TLS creation on the thread, collide with dlopen. Move the creation of BIO and jemalloc threads to after modules are loaded. plus small bugfix when trying to disable the jemalloc thread at runtime
-
由 antirez 提交于
This is what happened: 1. Instance starts, is a slave in the cluster configuration, but actually server.masterhost is not set, so technically the instance is acting like a master. 2. loadDataFromDisk() calls replicationCacheMasterUsingMyself() even if the instance is a master, in the case it is logically a slave and the cluster is enabled. So now we have a cached master even if the instance is practically configured as a master (from the POV of server.masterhost value and so forth). 3. clusterCron() sees that the instance requires to replicate from its master, because logically it is a slave, so it calls replicationSetMaster() that will in turn call replicationCacheMasterUsingMyself(): before this commit, this call would overwrite the old cached master, creating a memory leak.
-
由 Guy Benoish 提交于
-
由 喜欢兰花山丘 提交于
fix date +%s errata
-
由 antirez 提交于
-
由 antirez 提交于
-
由 Yuan Zhou 提交于
Signed-off-by: NYuan Zhou <yuan.zhou@intel.com>
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 zhaozhao.zz 提交于
-
由 Guy Benoish 提交于
Calling XADD with 0-0 or 0 would result in creating an empty key and storing it in the database. Even worse, because XADD will reply with error the action will not be replicated, creating a master-replica inconsistency
-
由 Loris Cro 提交于
-
由 Salvatore Sanfilippo 提交于
module documentation mismatches: loading and fork child for 5.0 branch
-