[jira] [Created] (HIVE-20050) Select is failing on a truncated table when warehouse is on HDFS encrypted zone
anishek created HIVE-20050: -- Summary: Select is failing on a truncated table when warehouse is on HDFS encrypted zone Key: HIVE-20050 URL: https://issues.apache.org/jira/browse/HIVE-20050 Project: Hive Issue Type: Bug Components: HiveServer2 Reporter: anishek Assignee: anishek -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-20049) hive.groupby.limit.extrastep should be false by default
Ashutosh Chauhan created HIVE-20049: --- Summary: hive.groupby.limit.extrastep should be false by default Key: HIVE-20049 URL: https://issues.apache.org/jira/browse/HIVE-20049 Project: Hive Issue Type: Task Components: Query Planning Reporter: Ashutosh Chauhan In fact this flag is not needed since FetchTask can enforce limit there is never a reason to have another vertex purely for limit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-20048) Consider enabling hive.fetch.task.aggr by default
Ashutosh Chauhan created HIVE-20048: --- Summary: Consider enabling hive.fetch.task.aggr by default Key: HIVE-20048 URL: https://issues.apache.org/jira/browse/HIVE-20048 Project: Hive Issue Type: Task Components: Physical Optimizer Reporter: Ashutosh Chauhan This optimization is in code base for long time. We shall consider enabling it by default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] hive pull request #384: HIVE-20025: Clean-up of event files created by HiveP...
GitHub user sankarh opened a pull request: https://github.com/apache/hive/pull/384 HIVE-20025: Clean-up of event files created by HiveProtoLoggingHook. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sankarh/hive HIVE-20025 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/hive/pull/384.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #384 commit 52c24baa28ed305f3be2b47f6246ffede0f08e6e Author: Sankar Hariappan Date: 2018-07-01T17:18:06Z HIVE-20025: Clean-up of event files created by HiveProtoLoggingHook. ---
[jira] [Created] (HIVE-20047) consider removing txnID argument for txn stats methods
Sergey Shelukhin created HIVE-20047: --- Summary: consider removing txnID argument for txn stats methods Key: HIVE-20047 URL: https://issues.apache.org/jira/browse/HIVE-20047 Project: Hive Issue Type: Sub-task Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Followup from HIVE-19975. W.r.t. write IDs and txn IDs, stats validity check currently verifies one of two things - that stats write ID is valid for query write ID list, or that stats txn ID (derived from write ID) is the same as the query txn ID. I'm not sure the latter check is needed; removing it would allow us to make a bunch of APIs a little bit simpler. [~ekoifman] do you have any feedback? Can any stats reader (e.g. compile) observe stats written by the same txn; but in such manner that it doesn't have the write ID of the same-txn stats writer, in its valid write ID list? I'm assuming it's not possible, e.g. in multi statement txn each query would have the previous same-txn writer for the same table in its valid write ID list? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-20046) remove NUM_FILES check or add a negative test
Sergey Shelukhin created HIVE-20046:
---
Summary: remove NUM_FILES check or add a negative test
Key: HIVE-20046
URL: https://issues.apache.org/jira/browse/HIVE-20046
Project: Hive
Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
{noformat}
// Since newly initialized empty table has 0 for the parameter.
if (Long.parseLong(statsParams.get(StatsSetupConst.NUM_FILES)) == 0) {
return true;
}
{noformat}
This doesn't look safe; # of files could be set to 0 by an invalid update, or
potentially a parallel update that we cannot see (not sure if this is possible;
there's some code in metastore that updates basic stats outside of the scope of
the query).
It would be better to remove this, and see if it breaks some tests. If we do
need this, there should be a negative test at some point
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-20045) Update hidden config list
Ashutosh Chauhan created HIVE-20045: --- Summary: Update hidden config list Key: HIVE-20045 URL: https://issues.apache.org/jira/browse/HIVE-20045 Project: Hive Issue Type: Task Components: Configuration Reporter: Ashutosh Chauhan -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-20044) Arrow Serde should pad char values and handle empty strings correctly
Teddy Choi created HIVE-20044: - Summary: Arrow Serde should pad char values and handle empty strings correctly Key: HIVE-20044 URL: https://issues.apache.org/jira/browse/HIVE-20044 Project: Hive Issue Type: Bug Components: Serializers/Deserializers Reporter: Teddy Choi Assignee: Teddy Choi When Arrow Serde serializes char values, it loses padding. Also when it counts empty strings, sometimes it makes a smaller number. It should pad char values and handle empty strings correctly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Review Request 66370: HIVE-18725: Improve error handling for subqueries if there is wrong column reference
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66370/ --- (Updated Июль 1, 2018, 8:55 д.п.) Review request for hive, Ashutosh Chauhan and Vineet Garg. Changes --- Rewrite the part of handling exception in CalcitePlanner. 1. If we got RuntimeException we just rethrow it. 2. If we got CalciteSemanticException with unsupported feature, we move to non-cbo analyzing. 3. If we got CalciteSemanticException w/o unsupported feature, we just rethrow it, wrapping it to new SemanticException(e.getMessage()), if we just wrap it, we will have redundant exception message with path of CalciteSemanticException. Also, I've tested the original cause in the Hive CLI, and it throws expected error, that column reference not found. Bugs: HIVE-18725 https://issues.apache.org/jira/browse/HIVE-18725 Repository: hive-git Description --- If there is a column reference within subquery which doesn't exist Hive throws misleading error message. Diffs (updated) - ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/CalciteSubquerySemanticException.java 4321a5c789 ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/CalciteViewSemanticException.java c2a4e94a03 ql/src/java/org/apache/hadoop/hive/ql/parse/CalcitePlanner.java e091f38bc6 ql/src/test/queries/clientnegative/subquery_non_exisiting_column.q PRE-CREATION ql/src/test/results/clientnegative/subquery_non_exisiting_column.q.out PRE-CREATION Diff: https://reviews.apache.org/r/66370/diff/5/ Changes: https://reviews.apache.org/r/66370/diff/4-5/ Testing --- Thanks, Igor Kryvenko
