Deny DML commands within explicit transactions in Hive#10798
Deny DML commands within explicit transactions in Hive#10798findepi merged 1 commit intotrinodb:masterfrom
Conversation
plugin/trino-hive/src/main/java/io/trino/plugin/hive/HiveMetadata.java
Outdated
Show resolved
Hide resolved
plugin/trino-hive/src/main/java/io/trino/plugin/hive/HiveMetadata.java
Outdated
Show resolved
Hide resolved
...rino-product-tests/src/main/java/io/trino/tests/product/hive/TestHiveTransactionalTable.java
Outdated
Show resolved
Hide resolved
05c033c to
2310135
Compare
There was a problem hiding this comment.
remove isTransactionalTable -- beginDelete won't be called for a non-acid table.
There was a problem hiding this comment.
I just tried the scenario of deleting from a non-transactional table that is being partitioned and this worked.
CREATE TABLE test2 (a_string varchar, a_integer int)
WITH (format = 'ORC', transactional = false, partitioned_by = ARRAY['a_integer']);
insert into test2 values ('hello', 1);
insert into test2 values ('world', 2);
insert into test2 values ('Trino', 1);
delete from test2 where a_integer =1 ;
I tend to think that it makes sense to keep the transactional table check.
There was a problem hiding this comment.
Are you saying that removing isTransactionalTable check here would break this scneario?
There was a problem hiding this comment.
The example above would call applyDelete, righ?
There was a problem hiding this comment.
trino:default> start transaction;
START TRANSACTION
trino:default> delete from test2 where a_integer =1 ;
DELETE
Query 20220128_112521_00030_bfch6, FINISHED, 1 node
http://localhost:8080/ui/query.html?20220128_112521_00030_bfch6
Splits: 1 total, 1 done (100.00%)
CPU Time: 0.0s total, 0 rows/s, 0B/s, 100% active
Per Node: 0.0 parallelism, 0 rows/s, 0B/s
Parallelism: 0.0
Peak Memory: 116B
0.43 [0 rows, 0B] [0 rows/s, 0B/s]
trino:default> select * from test2;
a_string | a_integer
----------+-----------
world | 2
(1 row)
Query 20220128_112531_00031_bfch6, FINISHED, 1 node
http://localhost:8080/ui/query.html?20220128_112531_00031_bfch6
Splits: 9 total, 9 done (100.00%)
CPU Time: 0.0s total, 166 rows/s, 49KB/s, 46% active
Per Node: 0.0 parallelism, 3 rows/s, 965B/s
Parallelism: 0.0
Peak Memory: 150B
0.31 [1 rows, 301B] [3 rows/s, 965B/s]
trino:default> rollback;
ROLLBACK
trino:default> select * from test2;
a_string | a_integer
----------+-----------
hello | 1
Trino | 1
world | 2
(3 rows)
Query 20220128_112538_00033_bfch6, FINISHED, 1 node
http://localhost:8080/ui/query.html?20220128_112538_00033_bfch6
Splits: 11 total, 11 done (100.00%)
CPU Time: 0.0s total, 187 rows/s, 54.9KB/s, 42% active
Per Node: 0.0 parallelism, 6 rows/s, 1.92KB/s
Parallelism: 0.0
Peak Memory: 150B
0.46 [3 rows, 900B] [6 rows/s, 1.92KB/s]
I've tried this functionality on master on config-default & config-hdp3 where the check is not present.
There was a problem hiding this comment.
trino:default> CREATE TABLE txtest (a_string varchar) WITH (format = 'ORC', transactional = true);
CREATE TABLE
trino:default> insert into txtest values ('a'), ('b'), ('c');
INSERT: 3 rows
Query 20220128_113930_00016_cj4we, FINISHED, 1 node
http://localhost:8080/ui/query.html?20220128_113930_00016_cj4we
Splits: 19 total, 19 done (100.00%)
CPU Time: 0.0s total, 0 rows/s, 0B/s, 7% active
Per Node: 0.0 parallelism, 0 rows/s, 0B/s
Parallelism: 0.0
Peak Memory: 416B
1.08 [0 rows, 0B] [0 rows/s, 0B/s]
trino:default> start transaction;
START TRANSACTION
trino:default> delete from txtest where a_string = 'a';
DELETE: 1 row
Query 20220128_113950_00018_cj4we, FINISHED, 1 node
http://localhost:8080/ui/query.html?20220128_113950_00018_cj4we
Splits: 10 total, 10 done (100.00%)
CPU Time: 0.1s total, 57 rows/s, 13KB/s, 50% active
Per Node: 0.1 parallelism, 6 rows/s, 1.36KB/s
Parallelism: 0.1
Peak Memory: 108B
0.50 [3 rows, 693B] [6 rows/s, 1.36KB/s]
trino:default> delete from txtest where a_string = 'b';
Query 20220128_113954_00019_cj4we failed: Tried to access metastore after transaction has been committed/aborted
java.lang.IllegalStateException: Tried to access metastore after transaction has been committed/aborted
at io.trino.plugin.hive.metastore.SemiTransactionalHiveMetastore.checkReadable(SemiTransactionalHiveMetastore.java:2441)
at io.trino.plugin.hive.metastore.SemiTransactionalHiveMetastore.getTable(SemiTransactionalHiveMetastore.java:217)
at io.trino.plugin.hive.HiveMetadata.getView(HiveMetadata.java:2391)
Tested on config-hdp3 on master
There was a problem hiding this comment.
i fail to understand the response.
it would help me if you did remove the check and the CI showed the failure for me.
There was a problem hiding this comment.
@findinpath just dro the isTransactionalTable() part of check.
It is not needed. It is already checked above via ensureTableSupportsDelete()
There was a problem hiding this comment.
I would not be strongly against verify(isTransactionalTable(table.getParameters()) but it feels overchatty.
2310135 to
9c1ca1a
Compare
findepi
left a comment
There was a problem hiding this comment.
https://github.com/trinodb/trino/pull/10798/files#r793590761
(i still fail to understand why not)
There was a problem hiding this comment.
i fail to understand the response.
it would help me if you did remove the check and the CI showed the failure for me.
9c1ca1a to
ff1f792
Compare
Nevermind. I am actually confused about how the Trino transactions work and that's why I went digressing with testing scenarios. I observed now that the |
|
please don't rebase when updating PR fortunately the diff this time was tiny (https://github.com/trinodb/trino/compare/9c1ca1ac52da5476c09de08a1b98a69c7a02edc2..ff1f79297a6594d078ddc496fc907036616b3d91), so that's just a reminder. |
do you recommend doing a rebase only at the end of the PR? |
no; use this: |
this is unrelated to this PR, but something to fix nonetheless @findinpath |
| @@ -1723,7 +1726,9 @@ public HiveInsertTableHandle beginInsert(ConnectorSession session, ConnectorTabl | |||
| if (isTransactional && retryMode != NO_RETRIES) { | |||
There was a problem hiding this comment.
"create table as select" can work as "insert into", so the table create in transaction will still be there after rollback...
Fixes #10760