catalog: fix SHOW CLUSTER REPLICAS and SHOW OBJECTS on id collision (SQL-531)#37789
Open
mtabebe wants to merge 3 commits into
Open
catalog: fix SHOW CLUSTER REPLICAS and SHOW OBJECTS on id collision (SQL-531)#37789mtabebe wants to merge 3 commits into
mtabebe wants to merge 3 commits into
Conversation
…SQL-531) Problem: Replica ids and catalog-item ids come from separate allocators that both render as `u<N>`, so a cluster replica and a catalog item can share one id string. That makes `mz_comments.id` unambiguous only together with `object_type`. `mz_show_cluster_replicas` and `mz_show_all_objects` LEFT JOIN `mz_comments` on id alone and put the `object_type` match in a trailing `WHERE`. On a LEFT JOIN that is wrong. When the only comment on the colliding id belongs to the other object type, the join produces a non-NULL right row that fails the `WHERE`, so the whole left row is dropped and the base object disappears from the view. Solution: Move the `object_type` match into the `JOIN ... ON`, the way `mz_show_columns` already does it. A wrong-type comment then fails to join, the base row survives, and `COALESCE(comment, '')` renders an empty comment. Tests: Add test/sqllogictest/comment_id_collision.slt. It covers both disappearance paths and checks that comments land on the right object when both objects on a colliding id are commented.
Problem: `mz_mcp_data_products` and `mz_mcp_data_product_details` LEFT JOIN `mz_comments` on id without an `object_type` predicate. Since replica ids and item ids share the `u<N>` namespace, a comment on a colliding cluster-replica can show up as the data product's description. And when the object has its own comment too, both comments join and the data-product row is duplicated. Solution: Add `object_type` predicates to the comment joins: `= 'index'` for the index comment, `= o.type` for the object and column comments. The existing `object_sub_id` predicates stay. They separate object comments from column comments, which is a different concern from the id collision. Tests: Extend `comment_id_collision.slt` with an MCP block. A materialized view whose id collides with a commented replica must report NULL as its description (not the replica's comment)
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem:
Replica ids and catalog-item ids come from separate allocators that both render as u,
so a cluster replica and a catalog item can share one id string.
mz_comments.id is unambiguous only together with object_type,
but several builtin views join mz_comments on id without matching object_type
in the ON clause.
in a trailing WHERE. On a LEFT JOIN that drops the base row when the only comment
on the colliding id belongs to the other object type, so a replica vanishes from
SHOW CLUSTER REPLICAS (or an object from SHOW OBJECTS) as soon as a colliding
item is commented.
on id with no object_type predicate at all. These feed COALESCE into a column, so rows
don't disappear, but a colliding comment can surface as the wrong description
or duplicate the row.
Solution:
Tests:
Adds test/sqllogictest/comment_id_collision.slt covering both disappearance paths,
the MCP wrong-comment/duplicate cases, and correct attribution when both
objects on a colliding id are commented.