- 04 Mar, 2020 1 commit
-
-
bodong.ybd authored
-
- 24 Feb, 2020 1 commit
-
-
antirez authored
-
- 19 Feb, 2020 1 commit
-
-
antirez authored
-
- 11 Feb, 2020 2 commits
- 10 Feb, 2020 1 commit
-
-
antirez authored
-
- 07 Feb, 2020 2 commits
- 06 Feb, 2020 1 commit
-
-
Guy Benoish authored
1. Call emptyDb even in case of diskless-load: We want modules to get the same FLUSHDB event as disk-based replication. 2. Do not fire any module events when flushing the backups array. 3. Delete redundant call to signalFlushedDb (Called from emptyDb).
-
- 05 Feb, 2020 1 commit
-
-
Oran Agra authored
-
- 04 Feb, 2020 2 commits
- 03 Feb, 2020 1 commit
-
-
Guy Benoish authored
Because "keymiss" is "special" compared to the rest of the notifications (Trying not to break existing apps using the 'A' format for notifications) Also updated redis.conf and module.c docs
-
- 02 Feb, 2020 1 commit
-
-
Leo Murillo authored
-
- 28 Jan, 2020 1 commit
-
-
antirez authored
-
- 27 Jan, 2020 1 commit
-
-
antirez authored
-
- 18 Dec, 2019 2 commits
-
-
antirez authored
-
zhaozhao.zz authored
-
- 17 Dec, 2019 3 commits
-
-
Madelyn Olson authored
-
Madelyn Olson authored
-
Madelyn Olson authored
-
- 09 Dec, 2019 1 commit
-
-
Oran Agra authored
the code in: c->flags &= ~(CLIENT_TRACKING|CLIENT_TRACKING_BROKEN_REDIR); will do sign extension and turn on all the high 31 bits no damage so far since we don't have any yet
-
- 28 Nov, 2019 1 commit
-
-
Oran Agra authored
Changes in behavior: - Change server.stream_node_max_entries from int64_t to long long, so that it can be used by the generic infra - standard error reply instead of "repl-backlog-size must be 1 or greater" and such - tls-port and a few TLS booleans were readable (config get) even when USE_OPENSSL was off (now they aren't) - syslog-enabled, syslog-ident, cluster-enabled, appendfilename, and supervised didn't have a get (now they do) - pidfile was initialized to NULL in InitServerConfig but had CONFIG_DEFAULT_PID_FILE in rewriteConfig (so the real default was "", but rewrite would cause it to be set), fixed the rewrite. - TLS config in server.h was uninitialized (if no tls config args were provided) Adding test for sanity and coverage
-
- 26 Nov, 2019 1 commit
-
-
Oran Agra authored
- add capability for each config to have a callback to check if value is valid and return error string will enable converting many of the remaining custom configs into generic ones (reducing the x4 repetition for set,get,config,rewrite) - add capability for each config to to run some update code after config is changed (only for CONFIG SET) will also enable converting many of the remaining custom configs into generic ones - add capability to move default values from server.h and server.c to config.c will reduce many excess lines in server.h and server.c (plus, no need to rebuild the entire code base when a default change 8-)) other behavior changes: - fix bug in bool config get (always returning 'yes') - fix a bug in modifying jemalloc-bg-thread at runtime (didn't call set_jemalloc_bg_thread, due to bad merge conflict resolution (my fault)) - side effect when a failed attempt to enable activedefrag at runtime, we now respond with -ERR and not with -DISABLED
-
- 22 Nov, 2019 2 commits
-
-
zhaozhao.zz authored
-
zhaozhao.zz authored
Random command like SPOP with count is replicated as some SREM operations, and store them in also_propagate array to propagate after the call, but this would break atomicity. To keep the command's atomicity, wrap also_propagate array with MULTI/EXEC.
-
- 19 Nov, 2019 3 commits
-
-
Johannes Truschnigg authored
This adds Makefile/build-system support for USE_SYSTEMD=(yes|no|*). This variable's value determines whether or not libsystemd will be linked at build-time. If USE_SYSTEMD is set to "yes", make will use PKG_CONFIG to check for libsystemd's presence, and fail the build early if it isn't installed/detected properly. If USE_SYSTEM is set to "no", libsystemd will *not* be linked, even if support for it is available on the system redis is being built on. For any other value that USE_SYSTEM might assume (e.g. "auto"), PKG_CONFIG will try to determine libsystemd's presence, and set up the build process to link against it, if it was indicated as being installed/available. This approach has a number of repercussions of its own, most importantly the following: If you build redis on a system that actually has systemd support, but no libsystemd-dev package(s) installed, you'll end up *without* support for systemd notification/status reporting support in redis-server. This changes established runtime behaviour. I'm not sure if the build system and/or the server binary should indicate this. I'm also wondering if not actually having systemd-notify-support, but requesting it via the server's config, should result in a fatal error now.
-
Johannes Truschnigg authored
Instead of replicating a subset of libsystemd's sd_notify(3) internally, use the dynamic library provided by systemd to communicate with the service manager. When systemd supervision was auto-detected or configured, communicate the actual server status (i.e. "Loading dataset", "Waiting for master<->replica sync") to systemd, instead of declaring readiness right after initializing the server process.
-
antirez authored
-
- 18 Nov, 2019 1 commit
-
-
antirez authored
-
- 14 Nov, 2019 1 commit
-
-
antirez authored
-
- 12 Nov, 2019 1 commit
-
-
Oran Agra authored
Reduce default minimum effort, so that when fragmentation is just detected, the impact on the latency will be minor. Reduce the default maximum effort, mainly to prevent a case were a sudden massive deletions, won't trigger an aggressive defrag that will cause latency. When activedefrag is disabled mid-run, reset the 'running' info field, and clear the scan cursor, so that when it'll be re-enabled, a new fresh scan will start. Clearing the 'running' variable is important since lowering the defragger tunables mid-scan won't help, the defragger only considers new threshold when a new scan starts, and during a scan it can only become more aggressive, (when more severe fragmentation is detected), it'll never go less aggressive. So by temporarily disabling activedefrag, one can lower th the tunables. Removing the experimantal warning.
-
- 11 Nov, 2019 1 commit
-
-
David Carlier authored
-
- 10 Nov, 2019 1 commit
-
-
Oran Agra authored
- the API name was odd, separated to two apis one for LRU and one for LFU - the LRU idle time was in 1 second resolution, which might be ok for RDB and RESTORE, but i think modules may need higher resolution - adding tests for LFU and for handling maxmemory policy mismatch
-
- 06 Nov, 2019 1 commit
-
-
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.
-
- 05 Nov, 2019 2 commits
-
-
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.
-
- 04 Nov, 2019 1 commit
-
-
Oran Agra authored
-
- 03 Nov, 2019 1 commit
-
-
Oran Agra authored
- Add RM_GetServerInfo and friends - Add auto memory for new opaque struct - Add tests for new APIs other minor fixes: - add const in various char pointers - requested_section in modulesCollectInfo was actually not sds but char* - extract new string2d out of getDoubleFromObject for code reuse Add module API for
-
- 31 Oct, 2019 1 commit
-
-
antirez authored
Using the is_key_ready() callback plus the reply callback later, creates different issues AFAIK: 1. More complex API. 2. We need to call the reply callback() ASAP if the is_key_ready() interface returned success, however the internals do not work in that way, so when the reply callback is called the setup could be different. To fix that, there is to break the current design that handles the unblocked clients asyncrhonously, and run the list ASAP.
-