- 10 Dec, 2018 4 commits
- 07 Dec, 2018 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
-
yura authored
-
- 04 Dec, 2018 2 commits
-
-
yongman authored
-
Madelyn Olson authored
-
- 02 Dec, 2018 1 commit
-
-
Oran Agra authored
these metrics become negative when RSS is smaller than the used_memory. This can easily happen when the program allocated a lot of memory and haven't written to it yet, in which case the kernel doesn't allocate any pages to the process
-
- 30 Nov, 2018 1 commit
-
-
zhaozhao.zz authored
-
- 28 Nov, 2018 2 commits
-
-
zhaozhao.zz authored
In MEMORY USAGE command, we count the key argv[2] into usage, but the argument in command may contains free spaces because of sdsMakeRoomFor. But the key in db never contains free spaces because we use sdsdup when dbAdd, so using the real key to count the usage is more accurate.
-
antirez authored
See #5612.
-
- 25 Nov, 2018 2 commits
-
-
David Carlier authored
Special treatment here as backtrace support is optional, cannot be found via pkg-config and similar neither.
-
David Carlier authored
FreeBSD/DragonFlyBSD does have backtrace only it does not belong to libc.
-
- 23 Nov, 2018 4 commits
-
-
Chris Lamb authored
If we encounter an unsupported protocol in the "bind" list, don't ipso-facto consider it a fatal error. We continue to abort startup if there are no listening sockets at all. This ensures that the lack of IPv6 support does not prevent Redis from starting on Debian where we try to bind to the ::1 interface by default (via "bind 127.0.0.1 ::1"). A machine with IPv6 disabled (such as some container systems) would simply fail to start Redis after the initiall call to apt(8). This is similar to the case for where "bind" is not specified: https://github.com/antirez/redis/issues/3894 ... and was based on the corresponding PR: https://github.com/antirez/redis/pull/4108 ... but also adds EADDRNOTAVAIL to the list of errors to catch which I believe is missing from there. This issue was raised in Debian as both <https://bugs.debian.org/900284> & <https://bugs.debian.org/914354>.
-
Chris Lamb authored
This really helps spot it in the logs, otherwise it does not look like a warning/error. For example: Creating Server TCP listening socket ::1:6379: bind: Cannot assign requested address ... is not nearly as clear as: Could not create server TCP listening listening socket ::1:6379: bind: Cannot assign requested address
-
yongman authored
-
yongman authored
-
- 21 Nov, 2018 1 commit
-
-
yongman authored
-
- 19 Nov, 2018 3 commits
-
-
antirez authored
This commit fixes #5570. It is a similar bug to one fixed a few weeks ago and is due to the range API to be called with NULL as "end ID" parameter instead of repeating again the start ID, to be sure that we selectively issue the entry with a given ID, or we get zero returned (and we know we should emit a NULL reply).
-
antirez authored
This fixes the issue reported in #5570. This was fixed the hard way, that is, propagating more information to the lower level API about this being a request to read just the history, so that the code is simpler and less likely to regress.
-
antirez authored
-
- 16 Nov, 2018 1 commit
-
-
yongman authored
-
- 15 Nov, 2018 1 commit
-
-
Weiliang Li authored
fix comment typo in util.c
-
- 11 Nov, 2018 1 commit
-
-
David Carlier authored
-
- 08 Nov, 2018 1 commit
-
-
David Carlier authored
-
- 07 Nov, 2018 1 commit
-
-
antirez authored
Thanks to @NicolasLM, see issue #5537.
-
- 06 Nov, 2018 2 commits
- 05 Nov, 2018 8 commits
-
-
artix authored
-
artix authored
- clusterManagerFixOpenSlot: ensure that the slot is unassigned before ADDSLOTS - clusterManagerFixSlotsCoverage: after cold migration, the slot configuration is now updated on all the nodes.
-
artix authored
-
artix authored
-
artix authored
-
artix authored
-
antirez authored
This bug had a double effect: 1. Sometimes entries may not be emitted, producing broken protocol where the array length was greater than the emitted entires, blocking the client waiting for more data. 2. Some other time the right entry was claimed, but a wrong entry was returned to the client. This fix should correct both the instances.
-
antirez authored
-