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
storage: avoid map lookup in raftRcvdMessages, replace with array #41573
storage: avoid map lookup in raftRcvdMessages, replace with array #41573
Conversation
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.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner and @nvanbenschoten)
pkg/storage/raft.go, line 28 at r1 (raw file):
func init() { if numRaftMsgTypes != len(raftpb.MessageType_name) {
I wonder if this should instead look for the max-raft-message-type in raftpb.MessageType_name
. The current code will fail if a new message type is added and an old one is removed.
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.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner and @petermattis)
pkg/storage/raft.go, line 28 at r1 (raw file):
Previously, petermattis (Peter Mattis) wrote…
I wonder if this should instead look for the max-raft-message-type in
raftpb.MessageType_name
. The current code will fail if a new message type is added and an old one is removed.
Is that really a concern? The order of the message types in the array doesn't need to be stable across builds, as long as all of the references to the message types remain. And if not, we'll already hit a compilation error elsewhere.
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.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner and @nvanbenschoten)
pkg/storage/raft.go, line 28 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Is that really a concern? The order of the message types in the array doesn't need to be stable across builds, as long as all of the references to the message types remain. And if not, we'll already hit a compilation error elsewhere.
The MessageType
enum values are encoded in the proto. My point was what happens if someone adds MsgBuyMeABeer = 19
and removes MsgCheckQuorum
. The number of elements in MessageType_name
remains at 19
, but raftRcvdMessages[MsgBuyMeABeer]
is an out-of-bounds slice access.
c1d14cd
to
702a46d
Compare
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @ajwerner and @petermattis)
pkg/storage/raft.go, line 28 at r1 (raw file):
Previously, petermattis (Peter Mattis) wrote…
The
MessageType
enum values are encoded in the proto. My point was what happens if someone addsMsgBuyMeABeer = 19
and removesMsgCheckQuorum
. The number of elements inMessageType_name
remains at19
, butraftRcvdMessages[MsgBuyMeABeer]
is an out-of-bounds slice access.
Ok, I see what you mean. How's that?
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @ajwerner and @nvanbenschoten)
pkg/storage/raft.go, line 28 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Ok, I see what you mean. How's that?
Looks good to me. Thanks.
Drive by cleanup with small perf impact. Release note: None
702a46d
to
2f8a222
Compare
bors r+ |
Build succeeded |
Drive by cleanup with small perf impact.
Release note: None