Prevent Redis from crashing from key tracking invalidations #11814
Conversation
|
@madolson. this solves the crash but not the problem right? we would still like to get invalidations when shrinking the invalidation table. |
Oh - NVM. noticed we will still send the invalidations just not queue them... |
Co-authored-by: Huang Zhw <huang_zhw@126.com>
|
When backporting to 6.2 and 7.0, we we needed the pause cron to be backported as well, I pulled out into this commit: madolson@a382b90. We also need some indicator we are in the command, the current flag is based off of the blocking refactor. EDIT: I think this fits, dc742bf. I'm happy Ran did the refactoring :). |
madolson
added
the
release-notes
|
So the last commit you referred to is an alternative instead of relying on the new flag? Any reason you didn't merge the pr yet? |
Yes |
(cherry picked from commit f7150c45bc5d6f03c8ba86a9a9296d024c6848dc)
) There is a built in limit to client side tracking keys, which when exceeded will invalidate keys. This occurs in two places, one in the server cron and other before executing a command. If it happens in the second scenario, the invalidations will be queued for later since current client is set. This queue is never drained if a command is not executed (through call) such as a multi-exec command getting queued. This results in a later server assert crashing.
) There is a built in limit to client side tracking keys, which when exceeded will invalidate keys. This occurs in two places, one in the server cron and other before executing a command. If it happens in the second scenario, the invalidations will be queued for later since current client is set. This queue is never drained if a command is not executed (through call) such as a multi-exec command getting queued. This results in a later server assert crashing.
Resolves #11715.
There is a built in limit to client side tracking keys, which when exceeded will invalidate keys. This occurs in two places, one in the server cron and other before executing a command. If it happens in the second scenario, the invalidations will be queued for later since current client is set. This queue is never drained if a command is not executed (through call) such as a multi-exec command getting queued. This results in a later server assert crashing.
Related: #9422.