Skip to content

catalog: fix SHOW CLUSTER REPLICAS and SHOW OBJECTS on id collision (SQL-531)#37789

Open
mtabebe wants to merge 3 commits into
MaterializeInc:mainfrom
mtabebe:ma/sql-531
Open

catalog: fix SHOW CLUSTER REPLICAS and SHOW OBJECTS on id collision (SQL-531)#37789
mtabebe wants to merge 3 commits into
MaterializeInc:mainfrom
mtabebe:ma/sql-531

Conversation

@mtabebe

@mtabebe mtabebe commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

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.

  • mz_show_cluster_replicas and mz_show_all_objects put the object_type match
    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.
  • mz_mcp_data_products and mz_mcp_data_product_details join mz_comments
    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:

  • Move the matches into the join, or add a predicate

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.

mtabebe added 3 commits July 21, 2026 10:29
…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)
@mtabebe
mtabebe marked this pull request as ready for review July 21, 2026 20:03
@mtabebe
mtabebe requested a review from a team as a code owner July 21, 2026 20:03
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.

1 participant