CREATE OR REPLACE TABLE on Iceberg never succeeds if metadata location was changed concurrently

[ivanvy-wix]

I’m not sure how to write a test with concurrent queries, but to reproduce manually:

1. Create a table

   CREATE TABLE t AS
   SELECT 1 AS v

2. Start a CREATE OR REPLACE TABLE query that takes some time to finish, I used a large-ish source table s which takes my test instance some time to scan through:

   CREATE OR REPLACE TABLE t AS
   SELECT count() FROM s WHERE some_column LIKE '%aa%'

3. While it’s running, update the table t (it should start after and finish before the previous query):

   INSERT INTO t VALUES (2)

4. Observe CREATE OR REPLACE TABLE fail with

   Metadata location [s3a://iceberg-bucket/schema.db/t/metadata/00002-3919e831-9f5b-43f9-b73c-4e21cd320b0d.metadata.json] is not same as table metadata location [s3a://iceberg-bucket/schema.db/t/metadata/00001-c651ded9-73e9-47da-986f-4237e8de34a9.metadata.json] for schema.t
   

I think it happens, because on every attempt to commit in BaseTransaction#commitReplaceTransaction(), the table’s metadata is getting refreshed and then, assuming it’s refreshed, Iceberg sets the base to current() before calling commit(base, current). But in AbstractIcebergTableOperations#refresh() Trino doesn’t reload metadata if the table is getting replaced. So every commit retry results in the same CommitFailedException which eventually exhausts max retries and fails the query.