You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hive: AlreadyExistsException from a resent create_table deletes the metadata of the table it created #18423
HiveTableOperations deletes the metadata of a table it has just created when a resent create_table returns AlreadyExistsException, which leaves a table in HMS that cannot be loaded.
What happens
HiveTableOperations.doCommit treats an AlreadyExistsException from create_table as a failed commit and deletes the new metadata file. That is right when another writer owns the name, but the exception can also answer our own request. RetryingMetaStoreClient, which HiveClientPool uses, resends create_table after a transport error. If the first request was applied and only its response was lost, the resend fails on the table the first request created.
This is the create-path counterpart of #11814, where a resent alter_table was misread as a concurrent modification and #12637 added a commit status check.
Reproduction
Register a metastore event listener whose onCreateTable sleeps for 5 seconds. It runs after the table is committed, so it only delays the create_table response.
Set hive.metastore.client.socket.timeout=2s and call catalog.createTable.
The client times out and resends the request:
MetaStoreClient lost connection. Attempting to reconnect (1 of 1) after 1s. createTable
org.apache.thrift.transport.TTransportException: java.net.SocketTimeoutException: Read timed out
createTable then fails although the table exists in HMS, and loadTable cannot read it:
org.apache.iceberg.exceptions.AlreadyExistsException: Table already exists: hivedb.repro_tbl
org.apache.iceberg.exceptions.NotFoundException: Failed to open input stream for file: .../metadata/00000-<uuid>.metadata.json
Proposed fix
On AlreadyExistsException, check whether the table now under the name has the UUID of the metadata being committed (as in trinodb/trino#31212):
Same UUID: the commit succeeded, so the files are kept.
Another table owns the name: the current behavior stays.
The check fails: the commit state is unknown, so the files are kept.
Willingness to contribute
I can contribute a fix for this bug independently
I would be willing to contribute a fix for this bug with guidance from the Iceberg community
I cannot contribute a fix for this bug at this time
Activity