- 19 Nov, 2019 16 commits
-
-
antirez authored
-
Oran Agra authored
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 authored
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 authored
-
喜欢兰花山丘 authored
fix date +%s errata
-
antirez authored
-
antirez authored
-
Yuan Zhou authored
Signed-off-by:
Yuan Zhou <yuan.zhou@intel.com>
-
antirez authored
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
-
Guy Benoish authored
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 authored
-
Salvatore Sanfilippo authored
module documentation mismatches: loading and fork child for 5.0 branch
-
Oran Agra authored
loading flag was missing from docs, and fork chidl indicator was removed from the code but left int he doc and header, re-adding it to the doc together with the missing function that was needed for it to work.
-
- 14 Nov, 2019 9 commits
- 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.
-
- 31 Oct, 2019 1 commit
-
-
antirez authored
See #6525, this likely creates a NULL deference if the client was terminated by Redis between the creation of the blocked client and the creation of the thread safe context.
-
- 25 Sep, 2019 9 commits
-
-
antirez authored
-
antirez authored
Thanks to @JohnSully for noticing this problem.
-
Oran Agra authored
these had severe impact for small zsets, for instance ones with just one element that is longer than 64 (causing it not to be ziplist encoded)
-
Oran Agra authored
for instance detached thread safe contexts, or various callbacks that don't provide a context.
-
antirez authored
See for reference PR #6337. Thanks to @git-hulk for spotting this.
-
antirez authored
Related to #6296.
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
-
- 05 Sep, 2019 2 commits
-
-
Salvatore Sanfilippo authored
RM_ReplyWithCString was missing registration
-
Salvatore Sanfilippo authored
backport module rdb aux data into 5.0
-