-
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
[release-15.0] Enable failures in tools/e2e_test_race.sh
and fix races (#13654)
#14009
Conversation
Signed-off-by: Florent Poinsard <florent.poinsard@outlook.fr>
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
|
* Copy fields from schema.Engine before modifying This fixes a race condition which caused protobuf marshaled schema data in _vt.schema_version rows to become corrupted when ColumnType was modified between the time when Field message sizes were calculated and when Field message data was written to the buffer. Signed-off-by: Brendan Dougherty <brendan.dougherty@shopify.com> * Acquire schema engine mutex while marshaling schema This change is purely defensive, but it may help avoid future race conditions caused by modifying shared schema structs while they are being marshaled to protobuf. Signed-off-by: Brendan Dougherty <brendan.dougherty@shopify.com> * reorganize imports and allocate slices with make Signed-off-by: Austen Lacy <austen.lacy@shopify.com> * gofmt Signed-off-by: Austen Lacy <austen.lacy@shopify.com> * flakey unit test Signed-off-by: Austen Lacy <austen.lacy@shopify.com> * Use common code to update column_type for both vstreamer and rowstream events in a thread-safe fashion. Fix related tests Signed-off-by: Rohit Nayak <rohit@planetscale.com> * Use DBName and not keyspace name while getting extended field info! Signed-off-by: Rohit Nayak <rohit@planetscale.com> * Fix TestVStreamSharded Signed-off-by: Rohit Nayak <rohit@planetscale.com> --------- Signed-off-by: Brendan Dougherty <brendan.dougherty@shopify.com> Signed-off-by: Austen Lacy <austen.lacy@shopify.com> Signed-off-by: Rohit Nayak <rohit@planetscale.com> Co-authored-by: Austen Lacy <austen.lacy@shopify.com> Co-authored-by: Rohit Nayak <rohit@planetscale.com>
for _, table := range se.tables { | ||
dbSchema.Tables = append(dbSchema.Tables, newMinimalTable(table)) | ||
} | ||
return dbSchema.MarshalVT() |
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.
@frouioui thanks for backporting this! Just wanted to note that in v15 (and v16) Vitess was still using proto.Marshal(dbSchema)
rather than dbSchema.MarshalVT()
for this. Not sure if it's important, or why the change was only made in later versions, but wanted to call it out in case we'd prefer to continue using proto.Marshal(dbSchema)
.
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.
Thank you for mentioning this.
@rohit-nayak-ps do you think we should revert to proto.Marshal(dbSchema)
?
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, good catch. To be consistent, we should just use proto.Marshal(dbSchema)
in v15/v16.
Description
This is a backport of #13654
Edit: this also backport #13045