changefeedccl: fix timestamp for desc fetches during planning#155872
Conversation
|
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
0b92c08 to
6d98f5b
Compare
Potential Bug(s) DetectedThe three-stage Claude Code analysis has identified potential bug(s) in this PR that may warrant investigation. Next Steps: After you review the findings, please tag the issue as follows:
|
| g := ctxgroup.WithContext(ctx) | ||
| targets, err := AllTargets(ctx, details, execCfg) | ||
| var changefeedStartTS hlc.Timestamp | ||
| if h := localState.progress.GetHighWater(); h != nil && !h.IsEmpty() { |
There was a problem hiding this comment.
Is the localstate highwater the right thing to have here so long as it's set? When do we expect to end up in each branch of this if?
Nit: initializing changefeedStartTS with an immediately invoked function might allow you to do early returns and might be a little nicer here.
There was a problem hiding this comment.
This logic was taken from distChangefeedFlow, which computed the highWater and schemaTS before starting the changefeed. I've broken out computing those two timestamps into computeDistChangefeedTimestamps.
To answer your question, this part was just to use the highwater if it already exists (changefeed resuming after pause or restart); otherwise, since there's no highwater, start from the statement time.
| } | ||
|
|
||
| prevTargets, err := AllTargets(ctx, prevDetails, p.ExecCfg()) | ||
| prevTargets, err := AllTargets(ctx, prevDetails, p.ExecCfg(), statementTime) |
There was a problem hiding this comment.
In this case we're altering a changefeed and getting the previous targets (i.e. before the alter). Is the right timestamp for this the statement time or something like prevProgress.GetHighWater()? My sense is it shouldn't make much of a difference, both should be at the same schema version etc and neither should have been GC'd.
There was a problem hiding this comment.
Good callout, fixed this.
| execCfg = ca.knobs.OverrideExecCfg(execCfg) | ||
| } | ||
| ca.targets, err = AllTargets(ctx, ca.spec.Feed, execCfg) | ||
| ca.targets, err = AllTargets(ctx, ca.spec.Feed, execCfg, *ca.spec.SchemaTs) |
There was a problem hiding this comment.
Since the schemaTs is marked as optional, do we need to check here in case it's null? Perhaps it shouldn't be optional.
Also confirming that since we expect to restart changefeeds on schemaChanges, this schemaTs should never need to be updated and it's never inaccurate.
nit: I think our preferred capitalization is SchemaTS
There was a problem hiding this comment.
Yes, need to check if it's null. Added that.
That's right, it's just for when the changefeed is first being started.
The capitalization for this is auto-generated from the protobuf, where it's schema_ts.
There was a problem hiding this comment.
You can override this with gogoproto.customname
| // when the changefeed resumes. | ||
| repeated cockroach.sql.jobs.jobspb.ResolvedSpan resolved_spans = 11 [(gogoproto.nullable) = false]; | ||
|
|
||
| optional util.hlc.Timestamp schema_ts = 12; |
There was a problem hiding this comment.
I think you should call out that we're adding a timestamp into the spec in the commit body/PR desc but that change seems appropriate.
| var schemaDescriptor catalog.SchemaDescriptor | ||
| var err error | ||
| f := func(ctx context.Context, txn descs.Txn) error { | ||
| if err := txn.KV().SetFixedTimestamp(ctx, schemaTS); err != nil { |
There was a problem hiding this comment.
Is there a scenario where this fails in a similar way to what we're seeing elsewhere? If so, a test for that case would be cool.
There was a problem hiding this comment.
Made a unit test for this, similar to the others, but not able to get it to fail on master.
|
Looking good, I like the approach. Left some comments. |
6d98f5b to
964bff9
Compare
Potential Bug(s) DetectedThe three-stage Claude Code analysis has identified potential bug(s) in this PR that may warrant investigation. Next Steps: Note: When viewing the workflow output, scroll to the bottom to find the Final Analysis Summary. After you review the findings, please tag the issue as follows:
|
964bff9 to
7260c71
Compare
Potential Bug(s) DetectedThe three-stage Claude Code analysis has identified potential bug(s) in this PR that may warrant investigation. Next Steps: Note: When viewing the workflow output, scroll to the bottom to find the Final Analysis Summary. After you review the findings, please tag the issue as follows:
|
428e1d2 to
3388e6d
Compare
3388e6d to
3fa6075
Compare
968f023 to
7d4d3c9
Compare
7d4d3c9 to
792e1fb
Compare
andyyang890
left a comment
There was a problem hiding this comment.
Looking good! Just have a few more minor comments
792e1fb to
267c416
Compare
056efe4 to
127e6c6
Compare
| case <-time.After(5 * time.Second): | ||
| t.Error("callback timed out waiting for table creation") | ||
| case <-ctx.Done(): | ||
| t.Error("context canceled") |
There was a problem hiding this comment.
Do we need to error when the context gets canceled? Could we just have an empty case/return here?
174403d to
cfcf402
Compare
Potential Bug(s) DetectedThe three-stage Claude Code analysis has identified potential bug(s) in this PR that may warrant investigation. Next Steps: Note: When viewing the workflow output, scroll to the bottom to find the Final Analysis Summary. After you review the findings, please tag the issue as follows:
|
When a changefeed is planned and executed, there are several places where target table descriptors are fetched. With a db-level changefeed, the set of tables can change during changefeed startup. Now, the timestamp is set to the schema timestamp for retrieving table descriptors. Adding a schema_ts to the protobuf for ChangeAggregatorSpec and ChangeFrontierSpec. Fixes: cockroachdb#154549 Epic: CRDB-1421 Release note: None
cfcf402 to
1d556c8
Compare
|
bors r=andyyang890,aerfrei |
155872: changefeedccl: fix timestamp for desc fetches during planning r=andyyang890,aerfrei a=log-head When a changefeed is planned and executed, there are several places where target table descriptors are fetched. With a db-level changefeed, the set of tables can change during changefeed startup. Now, the timestamp is set to the schema timestamp for retrieving table descriptors. Adding a schema_ts to the protobuf for ChangeAggregatorSpec and ChangeFrontierSpec. Fixes: #154549 Epic: CRDB-1421 Release note: None 157144: sql: add `ALTER TABLE ... SET/ADD IDENTITY` to the declarative schema… r=shghasemi a=shghasemi … changer This change adds support for `ALTER TABLE ... SET/ADD IDENTITY` to the declarative schema changer. This schema change operation runs using the legacy schema changer in versions older than 26.1. Epic: CRDB-31283 Fixes #142918 Release note (sql change): `ALTER TABLE ... SET/ADD GENERATED AS IDENTITY` is supported by the declerative schema changer in 26.1 or later. 157158: roachtest: do not build arm64 and fips if probabilitiy is 0 r=DarrylWong a=rail Previously, even when the probabilities for arm64 and fips builds were set to 0, the nightly roachtest script would still build those variants, which is unnecessary. This change modifies the script to skip building arm64 and fips variants when their respective probabilities are set to 0. Epic: none Release note: none Co-authored-by: Matthew Lougheed <matthew.lougheed@cockroachlabs.com> Co-authored-by: Shadi Ghasemitaheri <shadi.ghasemitaheri@cockroachlabs.com> Co-authored-by: Rail Aliiev <rail@iqchoice.com>
|
Build failed (retrying...): |
155872: changefeedccl: fix timestamp for desc fetches during planning r=andyyang890,aerfrei a=log-head When a changefeed is planned and executed, there are several places where target table descriptors are fetched. With a db-level changefeed, the set of tables can change during changefeed startup. Now, the timestamp is set to the schema timestamp for retrieving table descriptors. Adding a schema_ts to the protobuf for ChangeAggregatorSpec and ChangeFrontierSpec. Fixes: #154549 Epic: CRDB-1421 Release note: None 157144: sql: add `ALTER TABLE ... SET/ADD IDENTITY` to the declarative schema… r=shghasemi a=shghasemi … changer This change adds support for `ALTER TABLE ... SET/ADD IDENTITY` to the declarative schema changer. This schema change operation runs using the legacy schema changer in versions older than 26.1. Epic: CRDB-31283 Fixes #142918 Release note (sql change): `ALTER TABLE ... SET/ADD GENERATED AS IDENTITY` is supported by the declerative schema changer in 26.1 or later. Co-authored-by: Matthew Lougheed <matthew.lougheed@cockroachlabs.com> Co-authored-by: Shadi Ghasemitaheri <shadi.ghasemitaheri@cockroachlabs.com>
|
This PR was included in a batch that successfully built, but then failed to merge into master (it was a non-fast-forward update). It will be automatically retried. |
When a changefeed is planned and executed, there are several places where target table descriptors are fetched. With a db-level changefeed, the set of tables can change during changefeed startup. Now, the timestamp is set to the schema timestamp for retrieving table descriptors.
Adding a schema_ts to the protobuf for ChangeAggregatorSpec and ChangeFrontierSpec.
Fixes: #154549
Epic: CRDB-1421
Release note: None