-
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
vtexplain: Fix setting up the column information #15275
vtexplain: Fix setting up the column information #15275
Conversation
In vitessio#13312 we fixed how we encode names in information_schema queries. The problem there though is that the `GetColumnNamesQuery` string was also used inside `vtexplain`. It's usage there was not updated for the new escaping logic. This in turn leads to broken queries during `vtexplain` which then leads to a lot of logs. The issue here is not that we log a lot, we log that we actually do have a problem here which is the case. This fixes the underlying issue of not correctly generating the query as we should. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
@@ -618,7 +618,7 @@ func (t *explainTablet) handleSelect(query string) (*sqltypes.Result, error) { | |||
|
|||
// Gen4 supports more complex queries so we now need to | |||
// handle multiple FROM clauses | |||
tables := make([]*sqlparser.AliasedTableExpr, len(selStmt.From)) | |||
tables := make([]*sqlparser.AliasedTableExpr, 0, len(selStmt.From)) |
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.
Found this bug as well while debugging. We create it with the length, which means subsequent append
below would always create an even longer slice, negating this optimization plus having a lot of nil
entries in this slice.
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.
It's really a golang
design flaw. I've fallen for this many times.
@@ -474,8 +474,8 @@ func newTabletEnvironment(ddls []sqlparser.DDLStatement, opts *Options, collatio | |||
} | |||
tEnv.addResult(query, tEnv.getResult(likeQuery)) | |||
|
|||
likeQuery = fmt.Sprintf(mysqlctl.GetColumnNamesQuery, "database()", sanitizedLikeTable) | |||
query = fmt.Sprintf(mysqlctl.GetColumnNamesQuery, "database()", sanitizedTable) | |||
likeQuery = fmt.Sprintf(mysqlctl.GetColumnNamesQuery, "database()", mysqlctl.EncodeEntityName(sanitizedLikeTable)) |
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.
Is it correct to apply the encoding onto the like expression? It's not a table name.
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.
Yes, this creates a correctly escaped string from the input which is what we want here explicitly.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #15275 +/- ##
==========================================
- Coverage 67.44% 67.44% -0.01%
==========================================
Files 1561 1561
Lines 193193 193189 -4
==========================================
- Hits 130304 130296 -8
- Misses 62889 62893 +4 ☔ View full report in Codecov by Sentry. |
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.
LGTM. Can we add/update a test to catch things like this in the future?
I don't really have a good idea for how to add one. We only seem to log the errors, not fail on them. I wonder if we should fail on them instead but I don't really know enough about @vitessio/query-serving Does anyone of you have an idea how to test for this case here? |
9c769db
to
939de97
Compare
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
@@ -618,7 +618,7 @@ func (t *explainTablet) handleSelect(query string) (*sqltypes.Result, error) { | |||
|
|||
// Gen4 supports more complex queries so we now need to | |||
// handle multiple FROM clauses | |||
tables := make([]*sqlparser.AliasedTableExpr, len(selStmt.From)) | |||
tables := make([]*sqlparser.AliasedTableExpr, 0, len(selStmt.From)) |
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.
It's really a golang
design flaw. I've fallen for this many times.
There's already `sqltypes.EncodeStringSQL` which implements the exact same thing. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
…) (#15282) Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Co-authored-by: vitess-bot[bot] <108069721+vitess-bot[bot]@users.noreply.github.com>
…) (#15281) Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Co-authored-by: vitess-bot[bot] <108069721+vitess-bot[bot]@users.noreply.github.com>
…) (#15280) Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com> Co-authored-by: vitess-bot[bot] <108069721+vitess-bot[bot]@users.noreply.github.com>
In #13312 we fixed how we encode names in
information_schema
queries. The problem there though is that theGetColumnNamesQuery
string was also used insidevtexplain
. Its usage there was not updated for the new escaping logic.This in turn leads to broken queries during
vtexplain
which then leads to a lot of logs. The issue here is not that we log a lot, we log that we actually do have a problem here which is the case.This fixes the underlying issue of not correctly generating the query as we should.
Related Issue(s)
Part of #15242
Marked for backporting all the way to v16, since that's where the original change in #13312 was also back ported to.
Checklist