[ https://issues.apache.org/jira/browse/HIVE-26882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822714#comment-17822714 ]
Peter Vary commented on HIVE-26882: ----------------------------------- I see this in the MariaDB doc: https://mariadb.com/kb/en/mariadb-transactions-and-isolation-levels-for-sql-server-users/#isolation-levels-and-locks {quote} MariaDB isolation levels differ from SQL Server in the following ways: REPEATABLE READ does not acquire share locks on all read rows, nor a range lock on the missing values that match a WHERE clause. {quote} Which is not too encouraging. I would expect it to create a lock to prevent modifications. When I was working on this I have used 2 clients to connect to the same server, manually started the transactions, and used queries and updates to check the actual behavior. > 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)