Skip to content
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

When handling a scatter query vtgate should ensure consistent schema #4669

Open
setassociative opened this issue Feb 25, 2019 · 3 comments
Open
Labels
Component: Query Serving Type: Enhancement Logical improvement (somewhere between a bug and feature)

Comments

@setassociative
Copy link
Contributor

Overview of the Issue

If a table is in the middle of a schema migration it's possible for a scattered SELECT * query to return an inconsistent schema depending on the state of each tablet. When aggregating results we should ensure that each result contains the same set of fields and return an error if not.

Caveat: I'm not positive this is not already handled but based on commentary in this comment I don't believe it is.

Reproduction Steps

  1. Begin making a schema change
  2. Issue a scatter select * before the schema is applied to all shards
setassociative added a commit to tinyspeck/vitess that referenced this issue Feb 25, 2019
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
ajm188 pushed a commit to tinyspeck/vitess that referenced this issue Apr 28, 2020
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
ajm188 pushed a commit to tinyspeck/vitess that referenced this issue Jun 26, 2020
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
ameetkotian pushed a commit to tinyspeck/vitess that referenced this issue Aug 19, 2020
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
ameetkotian pushed a commit to tinyspeck/vitess that referenced this issue Aug 19, 2020
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
@harshit-gangal harshit-gangal added Component: Query Serving Type: Enhancement Logical improvement (somewhere between a bug and feature) labels Oct 29, 2020
setassociative added a commit to tinyspeck/vitess that referenced this issue Mar 3, 2021
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
setassociative added a commit to tinyspeck/vitess that referenced this issue Mar 4, 2021
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
setassociative added a commit to tinyspeck/vitess that referenced this issue Mar 17, 2021
Patch to handle this case while we move towards a permanent fix upstream.
cf. vitessio#4661 vitessio#4669
@indera-shsp
Copy link
Contributor

@setassociative Did you guys deploy this patch to production?

tinyspeck@3d3f660
I am encountering this issue when trying to connect to the Vstream

panic: runtime error: index out of range [4] with length 4

goroutine 30 [running]:
vitess.io/vitess/go/sqltypes.MakeRowTrusted(0xc0001be220, 0x4, 0x4, 0xc000169e50, 0x8, 0xdd0840, 0x1)
	/go/pkg/mod/vitess.io/[email protected]/go/sqltypes/result.go:170 +0x178
vitess.io/vitess/go/sqltypes.proto3ToRows(0xc0001be220, 0x4, 0x4, 0xc0001b4520, 0x1, 0x1, 0xc000cc7820, 0x415c78, 0x8)

@setassociative
Copy link
Contributor Author

@indera-shsp yes! we've been running with that patch in prod since Feb 2019; it never made it upstream because, iirc, there was some concern that we were essentially trading one case of panic for another. A call out though is that this case is generally extremely transient -- if you're seeing it every time you try to connect to a vstream there is likely something else going on and it suggests that the connecting endpoint doesn't have the right schema.

My suggestion would be to drop into the Vitess slack and you can get some more targeted advice.

@indera-shsp
Copy link
Contributor

Thanks for the reply... this issue seems to have two fixes, one patch and one PR in progress 🤣
(at least that how it seems to me)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Query Serving Type: Enhancement Logical improvement (somewhere between a bug and feature)
Projects
None yet
Development

No branches or pull requests

3 participants