[
https://issues.apache.org/jira/browse/HIVE-26882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824117#comment-17824117
]
Peter Vary commented on HIVE-26882:
-----------------------------------
[~lirui]: Is the same true if we read the previous value before modifying? Hive
does this. We read the table params and check the original values before
modifying them in the same transaction.
In your example, with something like this:
{code:java}
txn1> select * from tbl where key = 'k';
txn1> update tbl set val = 'v1' where key = 'k';
txn2> select * from tbl where key = 'k';
txn2> update tbl set val = 'v2' where key = 'k';
{code}
In this case the transactions are not \{SERIALIZABLE}, even by the SQL
definition. And I think the definition for \{REPEATABLE READ}
requirements are also would be broken
([https://jepsen.io/consistency/models/repeatable-read):]
{quote}Repeatable read is closely related to serializability, but unlike
serializable, it allows phantoms: if a transaction T1 reads a predicate, like
"the set of all people with the name “Dikembe”, then another transaction T2 may
create or modify a person with the name “Dikembe” before T1 commits. Individual
objects are stable once read, but the predicate itself may not be.
{quote}
But even the linked article says that the ANSI definition is not clear:
{quote}However, as Berenson, Bernstein, et al observed, the ANSI specification
allows multiple intepretations
{quote}
I expected that the isolation level definitions are clear, and it would prevent
the situation you mentioned above. If not, then I fully agree with your comment
that we need to fix/document this.
> 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)
