-
Notifications
You must be signed in to change notification settings - Fork 501
adapter: Further preparations for handling query plans in catalog implications #35837
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
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
What happens if the transaction fails? My assumption is that it ok to cache the expression of failed transactions... just confirming
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.
Similarly, how do we handle notices if the transaction doesn't succeed? Will this state just remain around forever?
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.
Good questions!
Expression cache on failed transaction: Yes, harmless. The cache entry is keyed by
(build_version, GlobalId, expr_type). If the transaction fails, thatGlobalIdnever lands in the catalog, so the entry is never looked up —get_global_expressions(in the follow-up PR) only queries GlobalIds fromOp::CreateItemops that are actually being committed. The orphaned entry sits inert in the persist shard until the next version bump cleans it up viaremove_prior_versions.Notices on failed transaction: This is actually the exact bug this PR fixes! Pre-fix,
emit_optimizer_noticesran before the catalog transaction, so the user saw spurious notices (e.g. "identical index already exists") even whenIF NOT EXISTShit a name collision and the item wasn't created. Post-fix:emit_raw_optimizer_notices_to_user) are emitted only in theOk(_)arm after the transaction succeeds.mz_optimizer_notices(viapersist_dataflow_metainfo) only happen inside the side-effect closure, which only runs on success.parse_itemduringapply_updatesfor committed transactions, so also inert on failure.The new
notice.pttest at the bottom of the PR pins this invariant for bothCREATE INDEX IF NOT EXISTSandCREATE MATERIALIZED VIEW IF NOT EXISTS.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.
Ah lol, Claude just went ahead and posted this when I asked it to draft a reply :D
Uh oh!
There was an error while loading. Please reload this page.
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.
But yeah, its answer is mostly right: The important thing is that this is only a small amount of orphaned data, and it gets cleaned up on the next version upgrade, because the expression cache is scoped to a version.