-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add support for query payload limit #6143
Conversation
4915b72
to
3dae409
Compare
Haven't looked deep in the code. Some high level considerations:
|
3dae409
to
e47d8c9
Compare
@sougou - This is how I’m thinking about the considerations you point out:
Although there is some overlap, I think this kind of granularity is a powerful lever to have in the toolkit. For context, our motivation for this, is that it is difficult for us to enforce the hard limits right now. We are going to towards that state, but we still have many places in our application where we can’t enforce this yet. With this new feature, we are going to be able to start enforcing limits with more granularity. I agree with the point around the concern around rowcount not being an accurate measure of payload size. That’s why we leaned more towards payload size. We have run into situations where we the rowcount is not that big, but the payload is. |
7daff90
to
c36d8d6
Compare
Agreed with everything Rafael said. Expanding on that a little: The gRPC limit is also one global limit for both SELECTs and INSERTs. We're not yet in a place where we're able to bring that down globally across the board. We've also seen a few incidents internally where the query payload size is large enough to start causing replication lag. Having this granularity of control around limits lets us fail those queries before they even hit the database. We also have a large number of tables that have started putting large protobufs in |
fac7e60
to
e15947c
Compare
Summary of changesI have incorporated provided feedback and have made the following updates to the initial implementation:
TestingIn addition to unit tests, I performed the following manual checks on a vtgate host:
|
query := sql | ||
statement := stmt | ||
bindVarNeeds := sqlparser.BindVarNeeds{} | ||
if !isValidPayloadSize(query) && !sqlparser.MaxPayloadSizeOverrideDirective(statement) { | ||
return nil, vterrors.New(vtrpcpb.Code_RESOURCE_EXHAUSTED, "query payload size above threshold") |
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.
Should this be Code_FAILED_PRECONDITION
instead?
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.
I think ResourceExhausted is fine, but it'd be nice to use a MySQL error code that indicates it's not retryable. In the upstream community Slack, we were discussing using MySQL error code 1153 for things like this and gRPC packet size exceeded going forward. I'm not sure where that MySQL error code is set and where the gRPC error code is set.
466e197
to
e43c927
Compare
Signed-off-by: Serry Park <me@serry.co>
Signed-off-by: Serry Park <me@serry.co>
Signed-off-by: Serry Park <me@serry.co>
e43c927
to
c82a3f2
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.
A few questions and some style / coding standard type changes.
Signed-off-by: Serry Park <me@serry.co>
76f8cdd
to
cc0840e
Compare
Add support for query payload limit
Add support for query payload limit
Add support for query payload limit
Add support for query payload limit
Overview
Currently, there is no way to enforce a limit on the query payload for an insert operations. This PR introduces a new comment directive, which, will enable us to configure threshold for insert query payloads.
Implementation
DirectiveMaxPayloadSize
for maximum payload size in bytes.Testing
Testing was done primarily via unit testing and covers the following cases: