harshitaajoshi commented on issue #17300: URL: https://github.com/apache/iceberg/issues/17300#issuecomment-5187737143
Looked into this, and there is a second form of the same bug that reproduces without needing multiple schemas. Both lookups pass `iceberg_tables` as a JDBC metadata pattern, where `_` is a single character wildcard, so an unrelated table like `iceberg1tables` matches on any database. Two things then go wrong: 1. `atomicCreateTable` decides `iceberg_tables` already exists and never creates it, which leaves the catalog permanently broken with "no such table: iceberg_tables". 2. `updateSchemaIfRequired` reads that table's columns and sets the schema version to V1 against a V0 catalog table. I have a fix that scopes both lookups to `conn.getCatalog()` and escapes the patterns with `dbMeta.getSearchStringEscape()`. It falls back to the current unrestricted behavior when the driver reports no catalog, which is what SQLite and Derby do. Two regression tests in `TestJdbcCatalog` reproduce the above on plain SQLite and fail without the change. One open question: I did not also narrow by `conn.getSchema()`. That would cover two schemas inside a single Postgres database, but it can produce a false negative when the catalog table is reachable through `search_path` from another schema. Happy to add it if you would rather cover that case now. Opening a PR shortly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
