Make commandlog config become memory config, make memory config support negative number
Make commandlog-request-larger-than and commandlog-reply-larger-than become the memory config, so we can use it conveniently. We don't use MEMORY_CONFIG before because memory config cannot be negative, now we support setting negative number in MEMORY CONFIG.
Codecov Report
:x: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 72.34%. Comparing base (ffdf222) to head (6157bd9).
:warning: Report is 46 commits behind head on unstable.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| src/config.c | 85.71% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## unstable #2648 +/- ##
============================================
+ Coverage 72.23% 72.34% +0.11%
============================================
Files 127 128 +1
Lines 70935 70147 -788
============================================
- Hits 51239 50749 -490
+ Misses 19696 19398 -298
| Files with missing lines | Coverage Δ | |
|---|---|---|
| src/util.c | 66.39% <ø> (-0.10%) |
:arrow_down: |
| src/config.c | 78.68% <85.71%> (+0.02%) |
:arrow_up: |
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
at first I also wanted to make it as memory config, but memory config cannot be negative, so we cannot use memory config
at first I also wanted to make it as memory config, but memory config cannot be negative, so we cannot use memory config
right, i forgot memory config can not use the negative number, but the code does not have any practical limitations? Like we can add a new xxx_CONFIG and make it support -1? It's a bit inconvenient not to be able to just use memory config for this memory bytes number.
Ok, it seems like folks in the monday meeting we were aligned about moving it to memory, but there some concerns about the change from ull2string -> ll2string which might truncate some values.
Ok, it seems like folks in the monday meeting we were aligned about moving it to memory, but there some concerns about the change from ull2string -> ll2string which might truncate some values.
yes, that is a problem...
And we actually have the problem in the unstable branch, like if we set maxmemory to 9223372036854775808 and doing a config rewrite, we will end up a maxmemory -8589934592gb in the config file. This will be a bug, i will try to fix it first in a different PR.
/* Rewrite a simple "option-name <bytes>" configuration option. */
void rewriteConfigBytesOption(struct rewriteConfigState *state,
const char *option,
long long value,
long long defvalue) {
char buf[64];
int force = value != defvalue;
sds line;
rewriteConfigFormatMemory(buf, sizeof(buf), value);
line = sdscatprintf(sdsempty(), "%s %s", option, buf);
rewriteConfigRewriteLine(state, option, line, force);
}