- 21 Jun, 2018 4 commits
-
-
michael-grunder authored
Unlike the BZPOP variants, these functions take a single key. This fixes an erroneous CROSSSLOT error when passing a count to a cluster enabled server.
-
Oran Agra authored
-
shenlongxing authored
-
youjiali1995 authored
-
- 20 Jun, 2018 1 commit
-
-
Guy Benoish authored
RESTORE now supports: 1. Setting LRU/LFU 2. Absolute-time TTL Other related changes: 1. RDB loading will not override LRU bits when RDB file does not contain the LRU opcode. 2. RDB loading will not set LRU/LFU bits if the server's maxmemory-policy does not match.
-
- 19 Jun, 2018 8 commits
-
-
Oran Agra authored
this reduces the extra 8 bytes we save before each pointer. but more importantly maybe, it makes the valgrind runs to be more similiar to our normal runs. note: the change in malloc_stats struct in server.h is to eliminate an name conflict. structs that are not typedefed are resolved from a separate name space.
-
antirez authored
-
Oran Agra authored
due to incorrect forward declaration, it didn't provide all arguments. this lead to random value being read from the stack and return of incorrect time, which in this case doesn't matter since no one uses it.
-
antirez authored
-
antirez authored
-
Oran Agra authored
-
Oran Agra authored
this complication in the code is from times were rdbSaveLen didn't support 64 bits.
-
antirez authored
Basically we cannot be sure that if the key is expired while writing the AOF, the main thread will surely find the key expired. There are possible race conditions like the moment at which the "now" is sampled, and the fact that time may jump backward. Think about the following: SET a 5 EXPIRE a 1 AOF rewrite starts after about 1 second. The child process finds the key expired, while in the main thread instead an INCR command is called against the key "a" immediately after a fork, and the scheduler was faster to give execution time to the main thread, so "a" is yet not expired. The main thread will generate an INCR a command to the AOF log that will be appended to the rewritten AOF file, but that INCR command will target a non existin "a" key, so a new non volatile key "a" will be created. Two observations: A) In theory by computing "now" before the fork, we should be sure that if a key is expired at that time, it will be expired later when the main thread will try to access to such key. However this does not take into account the fact that the computer time may jump backward. B) Technically we may still make the process safe by using a monotonic time source. However there were other similar related bugs, and in general the new "vision" is that Redis persistence files should represent the memory state without trying to be too smart: this makes the design more consistent, bugs less likely to arise from complex interactions, and in the end what is to fix is the Redis expire process to have less expired keys in RAM. Thanks to Oran Agra and Guy Benoish for writing me an email outlining this problem, after they conducted a Redis 5 code review.
-
- 18 Jun, 2018 6 commits
-
-
antirez authored
-
antirez authored
See #5011.
-
antirez authored
-
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.
-
antirez authored
Now a MAXLEN of 0 really does what it means: it will create a zero entries stream. This is useful in order to make sure that the behavior is identical to XTRIM, that must be able to reduce the stream to zero elements when MAXLEN is given. Also now MAXLEN with a count < 0 will return an error.
-
- 17 Jun, 2018 1 commit
-
-
antirez authored
-
- 14 Jun, 2018 3 commits
-
-
antirez authored
The ability of "SENTINEL SET" to change the reconfiguration script at runtime is a problem even in the security model of Redis: any client inside the network may set any executable to be ran once a failover is triggered. This option adds protection for this problem: by default the two SENTINEL SET subcommands modifying scripts paths are denied. However the user is still able to rever that using the Sentinel configuration file in order to allow such a feature.
-
antirez authored
Thanks to @kevinmcgehee for signaling the issue and reasoning about the consequences and potential fixes. Issue #5015.
-
Fuxin Hao authored
-
- 13 Jun, 2018 4 commits
-
-
zhaozhao.zz authored
-
shenlongxing authored
-
zhaozhao.zz authored
-
antirez authored
Thanks to Fakhri Zulkifli for reporting it. The fix switched to dynamic allocation, copying the final prompt in the static buffer only at the end.
-
- 12 Jun, 2018 12 commits
-
-
antirez authored
This way we let big endian systems to still load old RDB versions. However newver versions will be saved and loaded in a way that make RDB expires cross-endian again. Thanks to @oranagra for the reporting and the discussion about this problem, leading to this fix.
-
antirez authored
Currently it does not look it's sensible to generate events for streams consumer groups modification, being them metadata, however at least for key-level events, like the creation or removal of a consumer group, I added a few events here and there. Later we can evaluate if it makes sense to add more. From the POV instead of WAIT (in Redis transaciton) and signaling the key as modified, it looks like that the transaction should not fail when a stream is modified, so no calls are made in consumer groups related functions to signalModifiedKey().
-
antirez authored
Again thanks to @oranagra. The object idle time does not fit into an int sometimes: use the native type that the serialization function will get as argument, which is uint64_t.
-
antirez authored
Since the introduction of ZPOP makes this needed. Thanks to @oranagra for reporting.
-
antirez authored
I'm not sure how this escaped the attention of Redis users for years, but finally @oranagra reported this issue... Thanks to Oran.
-
antirez authored
-
antirez authored
-
Shen Longxing authored
The active-defrag-threshold-lower/active-defrag-threshold-upper min/max value in redis.conf should be consistent with 'config set' command.
-
antirez authored
See issue #5006. The comment in the code was also wrong and was rectified as well.
-
球状闪电 authored
fix geohasEncode bug when step > 31
-
antirez authored
See issue #5005 comments.
-
Baoyi Chen authored
fix [#5005](https://github.com/antirez/redis/issues/5005)
-
- 11 Jun, 2018 1 commit
-
-
antirez authored
A user with many connections (10 thousand) on a single Redis server reports in issue #4983 that sometimes Redis is idle becuase at the same time many clients need to resize their query buffer according to the old policy. It looks like this was created by the fact that we allow the query buffer to grow without problems to a size up to PROTO_MBULK_BIG_ARG normally, but when the client is idle we immediately are more strict, and a query buffer greater than 1024 bytes is already enough to trigger the resize. So for instance if most of the clients stop at the same time this issue should be easily triggered. This behavior actually looks odd, and there should be only a clear limit after we say, let's look at this query buffer to check if it's time to resize it. This commit puts the limit at PROTO_MBULK_BIG_ARG, and the check is performed both if compared to the peak usage the current usage is too big, or if the client is idle. Then when the check is performed, to waste just a few kbytes is considered enough to proceed with the resize. This should fix the issue.
-