prestodb/presto · error · PrestoException

ICEBERG_COMMIT_ERROR

ICEBERG_COMMIT_ERROR

Error message

Failed to commit Iceberg update to table: ${writableTableHandle.getTableName()}

What it means

This error is thrown by finishInsert when an Iceberg ValidationException is raised while committing appended data files to the table via appendFiles.commit(). It wraps the underlying Iceberg conflict/validation failure so the query fails with ICEBERG_COMMIT_ERROR instead of an internal Iceberg type.

Source

Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/IcebergAbstractMetadata.java:771

                .map(slice -> commitTaskCodec.fromJson(slice.getBytes()))
                .collect(toImmutableList());

        ImmutableSet.Builder<String> writtenFiles = ImmutableSet.builder();

        SchemaTableName schemaTableName = new SchemaTableName(writableTableHandle.getSchemaName(), writableTableHandle.getTableName().getTableName());
        Table icebergTable = getIcebergTable(session, schemaTableName);
        AppendFiles appendFiles = icebergTable.newAppend();
        Optional<String> branchName = writableTableHandle.getTableName().getBranchName();
        branchName.ifPresent(appendFiles::toBranch);

        commitTasks.forEach(task -> handleInsertTask(task, icebergTable, appendFiles, writtenFiles));
        try {
            appendFiles.set(PRESTO_QUERY_ID, session.getQueryId());
            appendFiles.commit();
        }
        catch (ValidationException e) {
            log.error(e, "ValidationException in finishWrite");
            throw new PrestoException(ICEBERG_COMMIT_ERROR, "Failed to commit Iceberg update to table: " + writableTableHandle.getTableName(), e);
        }

        return Optional.of(new HiveOutputMetadata(new HiveOutputInfo(commitTasks.stream()
                .map(CommitTaskData::getPath)
                .collect(toImmutableList()), icebergTable.location())));
    }

    private Optional<ConnectorOutputMetadata> finishWrite(ConnectorSession session, SchemaTableName tableName, IcebergWritableTableHandle writableTableHandle, Collection<Slice> fragments, ChangelogOperation operationType)
    {
        if (fragments.isEmpty()) {
            return Optional.empty();
        }

        Table icebergTable = getIcebergTable(session, tableName);

        List<CommitTaskData> commitTasks = fragments.stream()
                .map(slice -> commitTaskCodec.fromJson(slice.getBytes()))
                .collect(toImmutableList());

View on GitHub (pinned to 55bb57d202)

Solutions

Retry the INSERT query; Iceberg commits are optimistic and the write may succeed when re-run.
Reduce concurrency on the table: serialize writes or enable/rely on Iceberg optimistic-concurrency retry behavior in the engine.
Check the wrapped ValidationException in the Presto log for the exact cause (e.g. snapshot conflict, schema change) and address that root cause.
Shorten write duration so fewer concurrent commits overlap.

Example fix

// before
INSERT INTO iceberg_table SELECT * FROM large_source; // long-running, conflicts with other writers
// after
-- retry, or partition the load:
INSERT INTO iceberg_table SELECT * FROM large_source WHERE partition = 'a';
INSERT INTO iceberg_table SELECT * FROM large_source WHERE partition = 'b';

Defensive patterns

Strategy: retry

Validate before calling

-- before inserting, check for concurrent writers / inspect snapshot age
SELECT * FROM "t$snapshots" LIMIT 1;

Try / catch

// catch PrestoException with code ICEBERG_COMMIT_ERROR, back off, retry insert
try { insert(...); }
catch (PrestoException e) {
  if (e.getErrorCode().getCode() == ICEBERG_COMMIT_ERROR.toErrorCode().getCode()) retryWithBackoff();
  else throw e;
}

Prevention

Avoid many concurrent writers to the same Iceberg table
Split very large inserts into smaller batches to shorten commit windows
Schedule compaction/expiry jobs outside heavy write windows

When it happens

Trigger: An INSERT (or CREATE TABLE AS) finishes writing data files and calls appendFiles.commit(), but Iceberg rejects the metadata commit — typically because the table's snapshot changed concurrently (ConcurrentModificationException-style ValidationException) or the appended files fail snapshot validation.

Common situations: Concurrent writers committing to the same Iceberg table during a long INSERT; long-running CTAS queries whose target table snapshot was replaced mid-query; Iceberg table mutated by compaction/expiry jobs while an insert commits.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/e504d0884682f661. Report an issue: GitHub.