[
https://issues.apache.org/jira/browse/HIVE-26882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824800#comment-17824800
]
Rui Li commented on HIVE-26882:
-------------------------------
I found two options for MariaDB:
# Use SERIALIZABLE level.
# Use REPEATABLE_READ and direct SQL. Concurrent writes can be detected by
manually checking the number of updated rows. Pseudo code is in my [previous
comment|https://issues.apache.org/jira/browse/HIVE-26882?focusedCommentId=17823671&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17823671].
In our PoC of option 2, we only update the metadata location for an iceberg
table, which means other fields in HMS can be out of sync with iceberg
metadata. This is fine for us, because HMS only serves as a pointer to the
current metadata in our production. But I'm afraid it's not acceptable for the
community.
> Allow transactional check of Table parameter before altering the Table
> ----------------------------------------------------------------------
>
> Key: HIVE-26882
> URL: https://issues.apache.org/jira/browse/HIVE-26882
> Project: Hive
> Issue Type: Improvement
> Components: Standalone Metastore
> Reporter: Peter Vary
> Assignee: Peter Vary
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.3.10, 4.0.0-beta-1
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We should add the possibility to transactionally check if a Table parameter
> is changed before altering the table in the HMS.
> This would provide an alternative, less error-prone and faster way to commit
> an Iceberg table, as the Iceberg table currently needs to:
> - Create an exclusive lock
> - Get the table metadata to check if the current snapshot is not changed
> - Update the table metadata
> - Release the lock
> After the change these 4 HMS calls could be substituted with a single alter
> table call.
> Also we could avoid cases where the locks are left hanging by failed processes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
