Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sort out the mess around writable replicas and lookupKeyRead/Write #9572
Sort out the mess around writable replicas and lookupKeyRead/Write #9572
Changes from all commits
c09c811
c002931
49b2c48
710e9d9
ef55207
068e7a1
562b96f
3b1e307
6f01fb0
32a7045
cca77ac
a439aa9
aecc32c
34d1119
260c454
c78d43e
0ee4d68
623ca03
323dffc
f5def78
ae46106
d091ef9
ef10a77
34676f9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this assert assume that opening a key for write can’t be called from a redis command
but in RedisGraph when a SAVE command end we delete the temporary keys we created during the save process
we need to be able to workaround this assertion
this crashes redis in our tests
stack trace example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zuiderkwast we didn't want to break modules, and assumed that
c->cmd
will be a module command, but with notifications and events, that could be done from other random contexts.IIRC this assertion was just there in order to help us find native redis commands that are not flagged correctly.
it could have been sufficient to test that we're not on a writable-replica, but we thought that coverage for such a test will be low, and preferred to check our assumption on masters too.
As far as i can tell, our options now are:
please share your thoughts, and remind me what i forgot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be sure I understand what's happening: Is the
RM_OpenKey
triggered by something other than a module command, e.g. a keyspace notification or event, which is fired after some real command (SAVE) has executed? or before?If that's the case, can we set
c->cmd
to NULL before the firing the event? If we do, then this code will not appear to be part of any command, which I think is better than appearing as being run as part of some read-only command.Another question: Can this ever happen on a readonly replica? If yes, then perhaps we should set
force_delete_expired
to false here if we're on a read-only replica to keep it consistent with its primary, rather than only bypassing the assert.If we do, then I guess we can drop the assert entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what i know of RedisGraph, when this code happens on a replica, should always be in a fork child, but it could still be from within a command.
i.e. when a SYNC command is received and triggers an immediate fork, the fork child process will have
c->cmd
still set on the stack.What i don't like about nullifying
c->cmd
in the various event dispatches in module.c is that it's very far from the assertion.i.e. we'll have to backup, nullify, and restore
c->cmd
and add some comments explaining that it's done to avoid an assertion on the other side of town.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. This assert looks at things far away too...
I think we can remove the assertion and never set
force_delete_expired
on a writable replica:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zuiderkwast please make a PR.