- 04 Oct, 2019 3 commits
- 03 Oct, 2019 2 commits
- 02 Oct, 2019 5 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
-
antirez authored
-
Oran Agra authored
since the slowlog and other means that can help you detect the bad script are only exposed after the script is done. it might be a good idea to at least print the script name (sha) to the log when it timeouts.
-
- 01 Oct, 2019 2 commits
- 30 Sep, 2019 6 commits
- 27 Sep, 2019 9 commits
-
-
antirez authored
The correct way to access the module about a given IO context is to deference io->type->module, since io->ctx is only populated if the user requests an explicit context from an IO object.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
We don't want that the API could be used directly in an unsafe way, without checking if there is an active child. Now the safety checks are moved directly in the function performing the operations.
-
antirez authored
-
antirez authored
In theory currently there is only one active child, but the API may change or for bugs in the implementation we may have several (it was like that for years because of a bug). Better to wait for a specific pid and avoid consuing other pending children information.
-
antirez authored
-
antirez authored
We can't expect SIGUSR1 to have any specific value range, so let's define an exit code that we can handle in a special way. This also fixes an #include <wait.h> that is not standard.
-
- 26 Sep, 2019 3 commits
- 25 Sep, 2019 3 commits
-
-
filipecosta90 authored
-
antirez authored
-
antirez authored
-
- 23 Sep, 2019 7 commits
-
-
Mike A. Owens authored
SipHash expects a 128-bit key, and we were indeed generating 128-bits, but restricting them to hex characters 0-9a-f, effectively giving us only 4 bits-per-byte of key material, and 64 bits overall. Now, we skip the hex conversion and supply 128 bits of unfiltered random data.
-
filipecosta90 authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-