How trino handles conflicts during parallel writing?

[C-h-e-r-r-y]

Consider scenarios:

1. Simplest. Two writes append some data and try to commit same time. Am I right that second commiter just add new files? Am I right that there will be operation in metadata only without files rewriting? Or there will be full query rerun with additional files?
2. Complex one. Let say that there are 2 merge into actions that happens same time. Both created new files and started to commit changes. From Iceberg specification:

If the snapshot on which an update is based is no longer current, the writer must retry the update based on the new current version. Some operations support retry by re-applying metadata changes and committing, under well-defined conditions. For example, a change that rewrites files can be applied to a new table snapshot if all of the rewritten files are still in the table.

So let say that both merge into queries take 10 minutes. Both are finished (only metadata is needed to apply) first writer applied changes. What second write will do? Rerun merge into query on new table version? If there are dozen parallel writer - how many times query rerun will be? Could somebody please clarify? Any links to trino (not iceberg!) documentation are welcome. Maybe I miss something but this behaviour is not described in trino documentation.

[tlm365]

Any links to trino (not iceberg!) documentation are welcome. Maybe I miss something but this behaviour is not described in trino documentation.

Unfortunately, it just not related to Trino or compute engine, it on table format.
In fact, concurrent writes are handled on the Iceberg side by optimistic concurrency (or optimistic locking if you use AWS Glue Catalog)
Delta and Hudi have the same behavior.