[
https://issues.apache.org/jira/browse/HIVE-26882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824618#comment-17824618
]
Rui Li commented on HIVE-26882:
-------------------------------
I tried running these SQLs in each transaction, but none of them made the
concurrent writes fail. Also tried running {{DELETE}} in one transaction and
{{UPDATE}} in the other and still no failure.
{code:SQL}
select * from tbl;
update tbl set val = '..' where `key` = 'k';
{code}
{code:SQL}
select * from tbl where `key` = 'k';
update tbl set val = '..' where `key` = 'k';
{code}
{code:SQL}
select * from tbl where `key` = 'k' and val = 'v0';
update tbl set val = '..' where `key` = 'k' and val = 'v0';
{code}
{code:SQL}
select * from tbl;
update tbl set val = '..';
{code}
I also find the ANSI SQL not very clear about the isolation semantics, and
therefore vendors may have different interpretations of the standard.
So I prefer to use {{SERIALIZABLE}} by default, as it's most likely to work
with all RDBMS, and data consistency is more important than throughput here. We
can set {{REPEATABLE_READ}} for Postgres specifically, because the behavior is
clearly documented in Postgres and verified by test.
Allow users to override the level is fine, in case they know better about the
underlying DB.
> 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)
