Skip to content

Hive: AlreadyExistsException from a resent create_table deletes the metadata of the table it created #18423

Open

Description

@owenmonn

Apache Iceberg version

1.12.0 (latest release)

Query engine

None

Please describe the bug 🐞

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

  1. 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.
  2. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions