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

SHOW CHANGEFEED JOB displays implicit options after ALTER CHANGEFEED #78420

Closed
kathancox opened this issue Mar 24, 2022 · 1 comment · Fixed by #79325
Closed

SHOW CHANGEFEED JOB displays implicit options after ALTER CHANGEFEED #78420

kathancox opened this issue Mar 24, 2022 · 1 comment · Fixed by #79325
Assignees
Labels
A-cdc Change Data Capture C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-cdc

Comments

@kathancox
Copy link
Contributor

kathancox commented Mar 24, 2022

Describe the problem

ALTER CHANGEFEED output and SHOW CHANGEFEED JOB (post alter) both show options that the user might not have specifically defined in their original CREATE or ALTER statement. I’m assuming these are defaults that CRDB actually uses while creating the changefeed. (So, for example format = json when using a cloud storage sink.)

Just wanted to clarify since if a user runs SHOW CHANGEFEED JOB <job id> , before altering the changefeed, they will not see any implicit default options.

This can be described in the docs, but it may be worth considering whether SHOW CHANGEFEED should always show the implicit options, or the implicit options should not be displayed in ALTER or SHOW post an alter statement.

To Reproduce

CREATE CHANGEFEED FOR TABLE movr.users, movr.vehicles INTO 's3://my-bucket' WITH resolved, updated, diff;

Show changefeed shows me (exactly what I create):

746812475095810049 | CREATE CHANGEFEED FOR TABLE movr.users, movr.vehicles INTO 's3://my-bucket' WITH diff, resolved, updated | root | running | running: resolved=1647979480.529033710,0 | 2022-03-22 20:04:40.534619 | 2022-03-22 20:04:40.545617 | NULL | 2022-03-22 20:04:40.862273 | 1647979480529033710.0000000000 | | s3://my-bucket| {movr.public.users,movr.public.vehicles} | NULL | json

Then after pausing, and altering with:

ALTER CHANGEFEED 746812475095810049 DROP movr.users UNSET diff;

The output from this shows:

746812475095810049 | CREATE CHANGEFEED FOR TABLE vehicles INTO 's3://my-bucket' WITH envelope = 'wrapped', format = 'json', key_in_value, on_error = 'fail', resolved, schema_change_events = 'default', schema_change_policy = 'backfill', updated, virtual_columns = 'omitted'

Then I resume, and SHOW CHANGEFEED JOB again:

746812475095810049 | CREATE CHANGEFEED FOR TABLE vehicles INTO 's3://my-bucket' WITH envelope = 'wrapped', format = 'json', key_in_value, on_error = 'fail', resolved, schema_change_events = 'default', schema_change_policy = 'backfill', updated, virtual_columns = 'omitted' | root | running | running: resolved=1647979567.942785962,0 | 2022-03-22 20:04:40.534619 | 2022-03-22 20:04:40.545617 | NULL | 2022-03-22 20:09:04.723221 | 1647979741597546564.0000000000 | | s3://my-bucket | {movr.public.vehicles} | NULL | json

Expected behavior
I expected to see the alter output with just the changed options... basically no options I hadn't explicitly altered. So the original SHOW output had diff, resolved, updated. I'd expect the second SHOW response to show just resolved, updated after I removed diff.

It'd be great either way for the output to be consistent.

Jira issue: CRDB-14123

@kathancox kathancox added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. A-cdc Change Data Capture labels Mar 24, 2022
@blathers-crl blathers-crl bot added the T-cdc label Mar 24, 2022
@blathers-crl
Copy link

blathers-crl bot commented Mar 24, 2022

cc @cockroachdb/cdc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cdc Change Data Capture C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. T-cdc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants