LuciferYang opened a new issue, #13521: URL: https://github.com/apache/gravitino/issues/13521
### Version main branch ### Describe what's wrong The PostgreSQL rewrite of `deleteTableVersionByLegacyTimeline` emulates `DELETE ... LIMIT` with `WHERE table_id IN (SELECT table_id ... expired ...)`. But `table_version` holds one row per `(table_id, version)`: once any version of a table has an expired tombstone, the outer `DELETE` removes every version row of that table, including the live rows, silently dropping the stored format, properties, partitioning, and comment of a live table. The base SQL that MySQL and H2 run deletes only the expired tombstone rows. ### Error message and/or stacktrace No exception. On a PostgreSQL-backed deployment the current version row of a table disappears after the legacy-timeline cleanup runs (data loss). ### How to reproduce On a PostgreSQL backend: alter a table (which soft-deletes the old version row and inserts a new live one under the same `table_id`), wait until the old tombstone ages past the legacy timeline, then let the version GC run. The table's live version row is deleted too. ### Additional context The PostgreSQL statement should delete by physical row (`ctid`) so exactly the expired rows go, matching the row-level base SQL. -- 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]
