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

importccl: allow changes to referencing set or privileges on UDT #71016

Merged
merged 1 commit into from
Oct 12, 2021

Conversation

ajwerner
Copy link
Contributor

@ajwerner ajwerner commented Oct 1, 2021

In #69674 we enabled importing of tables which used UDTs. We added the caveat
that these types must not change during the import. In #70987, @ajstorm
uncovered that adding new usages of the type cause an illegal change. This is
a particularly painful limitation as all regional by row tables will use the
enum type of the database. That makes the limitation of import much more
extreme than just precluding renames or modifications of enums or their
members.

To fix this limitation, we permit changes to the referencing set which
occur during the import. We also permit changes to privileges as they
won't impact the correctness of the import.

Relates to #69706
Fixes #70987

Release note (enterprise change): Fixed a limitation of IMPORT for tables
using user-defined types whereby any change to the set of tables or views
which reference the type or any changes to privileges on the type during
the IMPORT would lead to failure. Now new references to the type or GRANT
or REVOKE operations performed while the IMPORT is ongoing will not cause
failure.

@ajwerner ajwerner requested review from adityamaru, ajstorm and a team October 1, 2021 20:34
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@ajstorm ajstorm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR made my day 🎉. Some comments below.

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @adityamaru and @ajwerner)


pkg/ccl/importccl/import_stmt.go, line 2362 at r1 (raw file):

			}
			equivalent, err := areEquivalentTypes(typeDesc.TypeDesc(), savedTypeDesc.Desc)
			if equivalent || err != nil {

Nit: Might just be me, but I find this reads better as:

if err != nil {
   return err
}
if equivalent {
   return nil
}

inferring that err == nil when equivalent == true takes a bit of reasoning which slows down the reading here.


pkg/ccl/importccl/import_stmt.go, line 2365 at r1 (raw file):

				return err
			}
			return errors.Newf("type descriptor %d has a different modification time than what"+

I think this message needs updating to describe that the type has fundamentally changed.


pkg/ccl/importccl/import_stmt_test.go, line 7295 at r1 (raw file):

			false,
		},
		{

Nit: Is it possible to modify TestImportMultiRegion to add some concurrency and validate that the scenario which originally flagged this issue is resolved (and stays resolved)?

@ajwerner ajwerner force-pushed the ajwerner/fix-udt-with-add-table branch from ce97ef1 to ff9f722 Compare October 1, 2021 22:24
Copy link
Contributor Author

@ajwerner ajwerner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @adityamaru and @ajstorm)


pkg/ccl/importccl/import_stmt.go, line 2362 at r1 (raw file):

Previously, ajstorm (Adam Storm) wrote…

Nit: Might just be me, but I find this reads better as:

if err != nil {
   return err
}
if equivalent {
   return nil
}

inferring that err == nil when equivalent == true takes a bit of reasoning which slows down the reading here.

Done.


pkg/ccl/importccl/import_stmt.go, line 2365 at r1 (raw file):

Previously, ajstorm (Adam Storm) wrote…

I think this message needs updating to describe that the type has fundamentally changed.

Done.


pkg/ccl/importccl/import_stmt_test.go, line 7295 at r1 (raw file):

Previously, ajstorm (Adam Storm) wrote…

Nit: Is it possible to modify TestImportMultiRegion to add some concurrency and validate that the scenario which originally flagged this issue is resolved (and stays resolved)?

Done.

@ajwerner ajwerner force-pushed the ajwerner/fix-udt-with-add-table branch from ff9f722 to 4e7766f Compare October 1, 2021 22:28
Copy link
Collaborator

@ajstorm ajstorm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @adityamaru)


pkg/ccl/importccl/import_stmt.go, line 2365 at r1 (raw file):

Previously, ajwerner wrote…

Done.

Looks good. One more think you might want to think of adding here is a hint. Something like "Retrying the IMPORT operation may succeed if the operation concurrently modifying the descriptor does not reoccur during the retry attempt."

Super nitty comment: I think you might want to add commas before and after "potentially incompatibly".

@ajstorm
Copy link
Collaborator

ajstorm commented Oct 4, 2021

Added backport flag to 21.2. IMO, this is a candidate for 21.2.1, but not a GA blocker.

In cockroachdb#69674 we enabled importing of tables which used UDTs. We added the caveat
that these types must not change during the import. In cockroachdb#70987, @ajstorm
uncovered that adding new usages of the type cause an illegal change. This is
a particularly painful limitation as all regional by row tables will use the
enum type of the database. That makes the limitation of import much more
extreme than just precluding renames or modifications of enums or their
members.

To fix this limitation, we permit changes to the referencing set which
occur during the import. We also permit changes to privileges as they
won't impact the correctness of the import.

Relates to cockroachdb#69706
Fixes cockroachdb#70987

Release note (enterprise change): Fixed a limitation of IMPORT for tables
using user-defined types whereby any change to the set of tables or views
which reference the type or any changes to privileges on the type during
the IMPORT would lead to failure. Now new references to the type or GRANT
or REVOKE operations performed while the IMPORT is ongoing will not cause
failure.
@ajwerner ajwerner force-pushed the ajwerner/fix-udt-with-add-table branch from 4e7766f to 2e99b40 Compare October 11, 2021 12:31
Copy link
Contributor Author

@ajwerner ajwerner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reworked the control flow as an early return would have allowed changes to subsequent types to slip through due to a return rather than a continue. Fortunately the linter caught that. Added a test and changed things around to avoid any need for continue.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @ajstorm)


pkg/ccl/importccl/import_stmt.go, line 2365 at r1 (raw file):

Previously, ajstorm (Adam Storm) wrote…

Looks good. One more think you might want to think of adding here is a hint. Something like "Retrying the IMPORT operation may succeed if the operation concurrently modifying the descriptor does not reoccur during the retry attempt."

Super nitty comment: I think you might want to add commas before and after "potentially incompatibly".

Done.

@ajwerner
Copy link
Contributor Author

TFTR!

bors r+

@craig
Copy link
Contributor

craig bot commented Oct 12, 2021

Build succeeded:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bulk-io: CREATE TABLE can cause IMPORT to fail when run concurrently on a multi-region database
4 participants