[jira] [Created] (HIVE-24796) [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId comparison
Kishen Das created HIVE-24796: - Summary: [HS2] Enhance DriverTxnHandler.isValidTxnListState logic to include tableId comparison Key: HIVE-24796 URL: https://issues.apache.org/jira/browse/HIVE-24796 Project: Hive Issue Type: Sub-task Components: HiveServer2 Reporter: Kishen Das In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. isValidTxnListState and later ensure there are no conflicting transactions by using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This doesn't work well, if there are external entities that drop and recreate the table with the same name. So, we should also make sure the tableId itself is not changed, after lock has been acquired. This Jira is to enhance the DriverTxnHandler.isValidTxnListState logic to include tableId comparison. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HIVE-24795) Cache tableId in SessionState
Kishen Das created HIVE-24795: - Summary: Cache tableId in SessionState Key: HIVE-24795 URL: https://issues.apache.org/jira/browse/HIVE-24795 Project: Hive Issue Type: Sub-task Components: HiveServer2 Reporter: Kishen Das Please go through https://issues.apache.org/jira/browse/HIVE-24794 to understand why this is required. Its basically to handle a corner case, in which a table gets dropped and recreated with the same name, after we gather information about all the tables and we acquire the lock. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HIVE-24794) Populate tableId in the response of get_valid_write_ids API
Kishen Das created HIVE-24794: - Summary: Populate tableId in the response of get_valid_write_ids API Key: HIVE-24794 URL: https://issues.apache.org/jira/browse/HIVE-24794 Project: Hive Issue Type: Sub-task Components: HiveServer2 Reporter: Kishen Das In HS2, after query compilation phase, we acquire lock in DriverTxnHandler. isValidTxnListState and later ensure there are no conflicting transactions by using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This doesn't work well, if there are external entities that drop and recreate the table with the same name. So, we should also make sure the tableId itself is not changed, after lock has been acquired. This Jira is to enhance getValidWriteIdList to return tableId as well. Idea is to cache the tableId in SessionState and later compare it with what getValidWriteIdList returns. If the table was dropped and recreated, the tableId will not match and we have to recompile the query. Caching the tableId in SessionState will be done as part of a separate Jira. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HIVE-24793) Compiler probe MJ selection algorithm fallback
Panagiotis Garefalakis created HIVE-24793: - Summary: Compiler probe MJ selection algorithm fallback Key: HIVE-24793 URL: https://issues.apache.org/jira/browse/HIVE-24793 Project: Hive Issue Type: Sub-task Reporter: Panagiotis Garefalakis Assignee: Panagiotis Garefalakis As per discussion on #1286 current probe MJ selection algorithm: * selects best MJ candidate (currently based on the distinct row ratio) * does some further processing - which may bail out Bailing out for the best candidate doesn't necessarily mean that we can not use a less charming candidate. The extra compilation can be wrapped into to for loop instead of selecting the best candidate the first part could be implemented as a priority logic -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HIVE-24792) Potential thread leak in Operation
Zhihua Deng created HIVE-24792: -- Summary: Potential thread leak in Operation Key: HIVE-24792 URL: https://issues.apache.org/jira/browse/HIVE-24792 Project: Hive Issue Type: Bug Components: HiveServer2 Reporter: Zhihua Deng The _scheduledExecutorService_ in _Operation_ does not shut down after scheduling delay operationlog cleanup, which may result to thread leak in hiveserver2... -- This message was sent by Atlassian Jira (v8.3.4#803005)
