[jira] [Created] (HIVE-26426) Handle StringIndexOutOfBoundsException in canCBOHandleAst() method.
Abhay created HIVE-26426: Summary: Handle StringIndexOutOfBoundsException in canCBOHandleAst() method. Key: HIVE-26426 URL: https://issues.apache.org/jira/browse/HIVE-26426 Project: Hive Issue Type: Bug Components: HiveServer2 Reporter: Abhay Assignee: Abhay The call to canHandleQbForCbo() can result in an StringIndexOutOfBoundsException. The assumption in the code is that the msg can only be null and we handle that but the msg can also be an empty string if the *verbose* is set to false. This can happen if INFO Logging is not enabled. We need to handle that case. https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/parse/CalcitePlanner.java#L913 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-26425) Skip SSL cert verification for downloading JWKS in HS2
Yu-Wen Lai created HIVE-26425: - Summary: Skip SSL cert verification for downloading JWKS in HS2 Key: HIVE-26425 URL: https://issues.apache.org/jira/browse/HIVE-26425 Project: Hive Issue Type: New Feature Reporter: Yu-Wen Lai Assignee: Yu-Wen Lai In a dev/test/staging environment, we would probably use letsencrypt staging certificate for a token generation service. However, its certificate is not accepted by JVM by default. To ease JWT testing in those kind of environments, we can introduce a property to disable the certificate verification just for JWKS downloads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-26424) When decimal type has overflowed the specified precision it must throw an error/warning instead of succeeding with NULL entries
Simhadri G created HIVE-26424:
-
Summary: When decimal type has overflowed the specified precision
it must throw an error/warning instead of succeeding with NULL entries
Key: HIVE-26424
URL: https://issues.apache.org/jira/browse/HIVE-26424
Project: Hive
Issue Type: Bug
Reporter: Simhadri G
When the decimal type has overflowed the specified precision, it results in
null entries as seen below:
{code:java}
0: jdbc:hive2://localhost:10001/> select cast(48932.19 AS DECIMAL(6,6));
+---+
| _c0 |
+---+
| NULL |
+---+
1 row selected (0.178 seconds){code}
This can be a significant issue when inserting a large amount of data from one
table to another. This can result in entire columns having NULL entries, as
seen below
{code:java}
0: jdbc:hive2://localhost:10001/> select * from t2;
+---+
| t2.num |
+---+
| 28367.81 |
| 49632.19 |
| NULL |
| 28367.81 |
| 49632.19 |
| NULL |
+---+
6 rows selected (0.202 seconds)
0: jdbc:hive2://localhost:10001/> create table t3(num decimal(20,10));
0: jdbc:hive2://localhost:10001/> insert into t3 select cast(t2.num as
decimal(5,2)) from t2;
12 rows affected (40.97 seconds)
0: jdbc:hive2://localhost:10001/> select * from t3;
+-+
| t3.num |
+-+
| NULL |
| NULL |
| NULL |
| NULL |
| NULL |
| NULL |
+-+
6 rows selected (0.205 seconds){code}
I think it would be better to throw an error as below instead of succeeding.
Similar to Mysql.
{code:java}
ERROR : Out of range value for column 'cast(num as decimal(5,2))' {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HIVE-26423) Make commons-pool2 a explicit dependency
John Sherman created HIVE-26423: --- Summary: Make commons-pool2 a explicit dependency Key: HIVE-26423 URL: https://issues.apache.org/jira/browse/HIVE-26423 Project: Hive Issue Type: Bug Components: HiveServer2 Reporter: John Sherman Assignee: John Sherman HIVE-26242 started using the commons-pool2 which is getting pulled in a transitive dependency through commons-dbcp2 or calcite-core. It would be better to make it an explicit dependency to ensure it gets packaged properly and/or things do not suddenly break if the transitive dependencies change. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-26422) Create table via spark-shell vs HS2 has discrepancy in authorization config policy
Sai Hemanth Gantasala created HIVE-26422: Summary: Create table via spark-shell vs HS2 has discrepancy in authorization config policy Key: HIVE-26422 URL: https://issues.apache.org/jira/browse/HIVE-26422 Project: Hive Issue Type: Bug Components: HiveServer2, Standalone Metastore Affects Versions: 4.0.0 Reporter: Sai Hemanth Gantasala Assignee: Sai Hemanth Gantasala Create table via spark-shell creates 4 privileges "INSERT,SELECT,UPDATE,DELETE" via table owner grants config whereas when we create an external table through hiveserver2 (using client like beeline) it doesn't create any owner privileges which is the desired condition. Note: In Hive's hive-site.xml, the following is set: hive.security.authorization.createtable.user.grants='' hive.security.authorization.createtable.group.grants='' hive.security.authorization.createtable.role.grants='' hive.security.authorization.createtable.owner.grants='' Also the setup is kerberized and uses ranger as an authorization service. So, when we create a table via spark-shell we shouldn't set hive.security.authorization.createtable.owner.grants in the code [https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/security/authorization/plugin/sqlstd/SQLStdHiveAccessController.java#L625] instead it should be picked using hive-site.xml. (which is already done in CreateTableAutomaticGrants class). The side effect of having table owner privileges set in the code, is that the TBL_PRIVS table in RDBMS is growing with every create table command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-26421) HmsClient atler_table_req is() is called twice when running an alter operation on iceberg table
László Pintér created HIVE-26421: Summary: HmsClient atler_table_req is() is called twice when running an alter operation on iceberg table Key: HIVE-26421 URL: https://issues.apache.org/jira/browse/HIVE-26421 Project: Hive Issue Type: Bug Reporter: László Pintér Assignee: László Pintér HMSClient alter_table_req() is triggered twice when altering an iceberg table. The first occurrence is right after returning from the HiveIcebergMetaHook#preAlterTable() and the second one is from HiveTableOperations#doCommit(). We should find a way to skip the first call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HIVE-26420) Configurable timeout for HiveSplitGenerator to wait for LLAP instances
László Bodor created HIVE-26420: --- Summary: Configurable timeout for HiveSplitGenerator to wait for LLAP instances Key: HIVE-26420 URL: https://issues.apache.org/jira/browse/HIVE-26420 Project: Hive Issue Type: Improvement Reporter: László Bodor -- This message was sent by Atlassian Jira (v8.20.10#820010)
