LuciferYang opened a new issue, #14603:
URL: https://github.com/apache/gravitino/issues/14603
### Version
main branch
### Describe what's wrong
`GravitinoMetadata.beginCreateTable` creates the table through the Gravitino
server first and then hands the write to the internal connector with
`beginInsert`. It drops the table only when `beginCreateTable` itself throws.
When the query fails later, while it runs or in `finishCreateTable`, nothing
drops the table: the internal connector's rollback only cleans up its own state
(Hive deletes the files the query wrote, JDBC drops its temporary table), and
the table that Gravitino created is not theirs to undo.
So a failed `CREATE TABLE AS SELECT` leaves an empty table behind, and
running the same statement again fails because the table exists. A native Trino
catalog leaves no table after a failed CTAS.
### Error message and/or stacktrace
None for the leftover table itself. The original query fails with its own
error, for example `Division by zero`.
### How to reproduce
In `TestGravitinoConnector` (Trino query runner with the memory internal
connector and `GravitinoMockServer`):
1. `create table "memory".db_01.src (a varchar, b int)` and `insert into
"memory".db_01.src values ('Alice', 1)`.
2. `create table "memory".db_01.ctas as select a, b / 0 as b from
"memory".db_01.src` fails with `Division by zero`.
3. `show tables from "memory".db_01` returns `src` and `ctas`.
4. Running the statement from step 2 again, without the division, fails.
### Additional context
A fix could record the tables that `beginCreateTable` created in the
transaction and drop them in `GravitinoConnector.rollback`, after the internal
rollback. #14550 adds that `rollback` override.
--
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]
