summaryrefslogtreecommitdiff
path: root/tests/sentinel
diff options
context:
space:
mode:
authorOran Agra <oran@redislabs.com>2021-07-29 12:11:29 +0300
committerGitHub <noreply@github.com>2021-07-29 12:11:29 +0300
commitb458b2999b749950c5ea9468cfa5ab74782848c3 (patch)
tree2fe56664d194020763cee630e2e20db8520069b1 /tests/sentinel
parent3db0f1a284e4fba703419b892b2d5b8d385afc06 (diff)
downloadredis-b458b2999b749950c5ea9468cfa5ab74782848c3.tar.gz
Fix LRU blue moon bug in RESTORE, RDB loading, module API (#9279)
The `lru_clock` and `lru` bits in `robj` save the least significant 24 bits of the unixtime (seconds since 1/1/1970), and wrap around every 194 days. The `objectSetLRUOrLFU` function, which is used in RESTORE with IDLETIME argument, and also in replica or master loading an RDB that contains LRU, and by a module API had a bug that's triggered when that happens. The scenario was that the idle time that came from the user, let's say RESTORE command is about 1000 seconds (e.g. in the `RESTORE can set LRU` test we have), and the current `lru_clock` just wrapped around and is less than 1000 (i.e. a period of 1000 seconds once in some 6 months), the expression in that function would produce a negative value and the code (and comment) specified that the best way to solve that is push the idle time backwards into the past by 3 months. i.e. an idle time of 3 months instead of 1000 seconds. instead, the right thing to do is to unwrap it, and put it near LRU_CLOCK_MAX. since now `lru_clock` is smaller than `obj->lru` it will be unwrapped again by `estimateObjectIdleTime`. bug was introduced by 052e03495f, but the code before it also seemed wrong.
Diffstat (limited to 'tests/sentinel')
0 files changed, 0 insertions, 0 deletions