[jira] [Created] (IMPALA-7527) Expose fetch-from-catalogd cache and latency metrics in profiles
Todd Lipcon created IMPALA-7527: --- Summary: Expose fetch-from-catalogd cache and latency metrics in profiles Key: IMPALA-7527 URL: https://issues.apache.org/jira/browse/IMPALA-7527 Project: IMPALA Issue Type: Sub-task Affects Versions: Impala 3.1.0 Reporter: Todd Lipcon Assignee: Todd Lipcon Since we now have some caching and potential remote calls on the planning path, it's important to be able to understand how that contributes to the performance of planning. This JIRA tracks adding such information to the profile. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603821#comment-16603821
]
bharath v commented on IMPALA-7526:
---
[~fredyw] Assigning this to you since you added this dependency. Feel free to
un/re-assign.
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Assignee: Fredy Wijaya
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}):
> Cannot access ${distMgmtSnapshotsUrl} with type default using the available
> connector factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed.
> Look above for specific messages explaining why the rule failed. -> [Help 1]
> [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]
> mvn -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7526:
--
Description:
I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
specific to those kinds of builds. Error message as follows
{noformat}
[WARNING] Could not transfer metadata
com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}):
Cannot access ${distMgmtSnapshotsUrl} with type default using the available
connector factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
[INFO] BUILD FAILURE [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
(enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
have failed.
Look above for specific messages explaining why the rule failed. -> [Help 1]
[ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] [ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]
mvn -B install -DskipTests exited with code 0
{noformat}
[1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
[2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
[3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
was:
I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
specific to those kinds of builds. Error message as follows
[WARNING] Could not transfer metadata
com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
${distMgmtSnapshotsUrl} with type default using the available connector
factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
[INFO] BUILD FAILURE [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
(enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
have failed. Look above for specific messages explaining why the rule failed.
-> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
full debug logging. [ERROR] [ERROR] For more information about the errors and
possible solutions, please read the following articles: [ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
-B install -DskipTests exited with code 0
[1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
[2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
[3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}):
> Cannot access ${distMgmtSnapshotsUrl} with type default using the available
> connector factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed.
> Look above for specific messages explaining why the rule failed. -> [Help 1]
> [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]
> mvn -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent
[jira] [Assigned] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v reassigned IMPALA-7526:
-
Assignee: Fredy Wijaya
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Assignee: Fredy Wijaya
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}):
> Cannot access ${distMgmtSnapshotsUrl} with type default using the available
> connector factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed.
> Look above for specific messages explaining why the rule failed. -> [Help 1]
> [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException]
> mvn -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7526:
--
Description:
I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
specific to those kinds of builds. Error message as follows
[WARNING] Could not transfer metadata
com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
${distMgmtSnapshotsUrl} with type default using the available connector
factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
[INFO] BUILD FAILURE [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
(enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
have failed. Look above for specific messages explaining why the rule failed.
-> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
full debug logging. [ERROR] [ERROR] For more information about the errors and
possible solutions, please read the following articles: [ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
-B install -DskipTests exited with code 0
[1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
[2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
[3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
was:
I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
specific to those kinds of builds. Error message as follows
{noformat}
[WARNING] Could not transfer metadata
com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
${distMgmtSnapshotsUrl} with type default using the available connector
factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
[INFO] BUILD FAILURE [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
(enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
have failed. Look above for specific messages explaining why the rule failed.
-> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
full debug logging. [ERROR] [ERROR] For more information about the errors and
possible solutions, please read the following articles: [ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
-B install -DskipTests exited with code 0
{noformat}
[1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
[2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
[3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
> ${distMgmtSnapshotsUrl} with type default using the available connector
> factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed. Look above for specific messages explaining why the rule failed.
> -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
> Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
> full debug logging. [ERROR] [ERROR] For more information about the errors and
> possible solutions, please read the following articles: [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
> -B install -DskipTests exited with code 0
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7526:
--
Affects Version/s: Impala 2.13.0
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
> ${distMgmtSnapshotsUrl} with type default using the available connector
> factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed. Look above for specific messages explaining why the rule failed.
> -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
> Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
> full debug logging. [ERROR] [ERROR] For more information about the errors and
> possible solutions, please read the following articles: [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
> -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7526:
--
Component/s: Frontend
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
> ${distMgmtSnapshotsUrl} with type default using the available connector
> factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed. Look above for specific messages explaining why the rule failed.
> -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
> Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
> full debug logging. [ERROR] [ERROR] For more information about the errors and
> possible solutions, please read the following articles: [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
> -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[
https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7526:
--
Description:
I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
specific to those kinds of builds. Error message as follows
{noformat}
[WARNING] Could not transfer metadata
com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
${distMgmtSnapshotsUrl} with type default using the available connector
factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
[INFO] BUILD FAILURE [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
(enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
have failed. Look above for specific messages explaining why the rule failed.
-> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
full debug logging. [ERROR] [ERROR] For more information about the errors and
possible solutions, please read the following articles: [ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
-B install -DskipTests exited with code 0
{noformat}
[1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
[2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
[3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
> Intermittent fe compilation failure due to failure of mvn enforcer rules
>
>
> Key: IMPALA-7526
> URL: https://issues.apache.org/jira/browse/IMPALA-7526
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> I ran into this thrice on clang-tidy builds [1,2,3] but I don't think it is
> specific to those kinds of builds. Error message as follows
> {noformat}
> [WARNING] Could not transfer metadata
> com.cloudera.cdh:cdh-root:6.x-SNAPSHOT/maven-metadata.xml from/to
> ${distMgmtSnapshotsId} (${distMgmtSnapshotsUrl}): Cannot access
> ${distMgmtSnapshotsUrl} with type default using the available connector
> factories: BasicRepositoryConnectorFactory [WARNING] Rule 0:
> org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
> [INFO] BUILD FAILURE [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-banned-dependencies) on project impala-frontend: Some Enforcer rules
> have failed. Look above for specific messages explaining why the rule failed.
> -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run
> Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable
> full debug logging. [ERROR] [ERROR] For more information about the errors and
> possible solutions, please read the following articles: [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException] mvn
> -B install -DskipTests exited with code 0
> {noformat}
> [1] https://jenkins.impala.io/job/clang-tidy-ub1604/2939/
> [2] https://jenkins.impala.io/job/clang-tidy-ub1604/2976/
> [3] https://jenkins.impala.io/job/clang-tidy-ub1604/2959/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn
bharath v created IMPALA-7526: - Summary: Intermittent fe compilation failure due to failure of mvn Key: IMPALA-7526 URL: https://issues.apache.org/jira/browse/IMPALA-7526 Project: IMPALA Issue Type: Bug Reporter: bharath v -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7526) Intermittent fe compilation failure due to failure of mvn enforcer rules
[ https://issues.apache.org/jira/browse/IMPALA-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath v updated IMPALA-7526: -- Summary: Intermittent fe compilation failure due to failure of mvn enforcer rules (was: Intermittent fe compilation failure due to failure of mvn) > Intermittent fe compilation failure due to failure of mvn enforcer rules > > > Key: IMPALA-7526 > URL: https://issues.apache.org/jira/browse/IMPALA-7526 > Project: IMPALA > Issue Type: Bug >Reporter: bharath v >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7481) Impala Doc: Deprecated file-based authorization
[ https://issues.apache.org/jira/browse/IMPALA-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7481: Labels: future_release_doc (was: ) > Impala Doc: Deprecated file-based authorization > --- > > Key: IMPALA-7481 > URL: https://issues.apache.org/jira/browse/IMPALA-7481 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Affects Versions: Impala 3.0 >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-5004) Switch to sorting node for large TopN queries
[ https://issues.apache.org/jira/browse/IMPALA-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Volker reassigned IMPALA-5004: --- Assignee: Sahil Takiar > Switch to sorting node for large TopN queries > - > > Key: IMPALA-5004 > URL: https://issues.apache.org/jira/browse/IMPALA-5004 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 2.9.0 >Reporter: Lars Volker >Assignee: Sahil Takiar >Priority: Major > > As explained by [~tarmstrong] in IMPALA-4995: > bq. We should also consider switching to the sort operator for large limits. > This allows it to spill. The memory requirements for TopN also are > problematic for large limits, since it would allocate large vectors that are > untracked and also require a large amount of contiguous memory. > There's already logic to select TopN vs. Sort: > [planner/SingleNodePlanner.java#L289|https://github.com/apache/incubator-impala/blob/master/fe/src/main/java/org/apache/impala/planner/SingleNodePlanner.java#L289] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-6964) Track stats about column and page sizes in Parquet reader
[ https://issues.apache.org/jira/browse/IMPALA-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Volker reassigned IMPALA-6964: --- Assignee: Sahil Takiar > Track stats about column and page sizes in Parquet reader > - > > Key: IMPALA-6964 > URL: https://issues.apache.org/jira/browse/IMPALA-6964 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Tim Armstrong >Assignee: Sahil Takiar >Priority: Major > Labels: observability, parquet, ramp-up > > It would be good to have stats for scanned parquet data about page sizes. We > currently can't tell much about the "shape" of the parquet pages from the > profile. Some questions that are interesting: > * How big is each column? I.e. total compressed and decompressed size read. > * How big are pages on average? Either compressed or decompressed size > * What is the compression ratio for pages? Could be inferred from the above > two. > I think storing all the stats in the profile per-column would be too much > data, but we could probably infer most useful things from higher-level > aggregates. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-6249) Expose CMAKE_BUILD_TYPE via web UI for build type detection
[ https://issues.apache.org/jira/browse/IMPALA-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Volker reassigned IMPALA-6249: --- Assignee: Sahil Takiar > Expose CMAKE_BUILD_TYPE via web UI for build type detection > --- > > Key: IMPALA-6249 > URL: https://issues.apache.org/jira/browse/IMPALA-6249 > Project: IMPALA > Issue Type: Improvement > Components: Infrastructure >Reporter: Tim Armstrong >Assignee: Sahil Takiar >Priority: Minor > > IMPALA-6241 added a .cmake_build_type file with the CMAKE_BUILD_TYPE value > for the last build. The file is used to detect the type of the build that the > python tests are running against. However, this assumes that the tests are > running from the same directory that the Impala cluster under test was built > from, which isn't necessarily true for all dev workflows and for remote > cluster tests. > It would be convenient if CMAKE_BUILD_TYPE was exposed from the Impalad web > UI. Currently we expose DEBUG/RELEASE depending on the value of NDEBUG - see > GetVersionString() and impalad-host:25000/?json=true, but we could expose the > precise build type, then allow the python tests to parse it from the web UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7525) Impala Doc: Document SHOW GRANT USER
[ https://issues.apache.org/jira/browse/IMPALA-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7525: Target Version: Impala 3.1.0 > Impala Doc: Document SHOW GRANT USER > > > Key: IMPALA-7525 > URL: https://issues.apache.org/jira/browse/IMPALA-7525 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc > > Update documents to reflect new GRANT, REVOKE, and SHOW statements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7525) Impala Doc: Document SHOW GRANT USER
[ https://issues.apache.org/jira/browse/IMPALA-7525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7525: Description: (was: Update documents to reflect new GRANT, REVOKE, and SHOW statements.) > Impala Doc: Document SHOW GRANT USER > > > Key: IMPALA-7525 > URL: https://issues.apache.org/jira/browse/IMPALA-7525 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7525) Impala Doc: Document SHOW GRANT USER
Alex Rodoni created IMPALA-7525: --- Summary: Impala Doc: Document SHOW GRANT USER Key: IMPALA-7525 URL: https://issues.apache.org/jira/browse/IMPALA-7525 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni Update documents to reflect new GRANT, REVOKE, and SHOW statements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7367) Pack StringValue, CollectionValue and TimestampValue slots
[
https://issues.apache.org/jira/browse/IMPALA-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603626#comment-16603626
]
Jim Apple commented on IMPALA-7367:
---
[~poojanilangekar], that sounds like a good approach. There are many other
things we can take a look at regarding the boost issue, including patching
boost or using components from {{std::}}.
> Pack StringValue, CollectionValue and TimestampValue slots
> --
>
> Key: IMPALA-7367
> URL: https://issues.apache.org/jira/browse/IMPALA-7367
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Pooja Nilangekar
>Priority: Major
> Labels: perfomance
> Attachments: 0001-WIP.patch
>
>
> This is a follow-on to finish up the work from IMPALA-2789. IMPALA-2789
> didn't actually fully pack the memory layout because StringValue,
> TimestampValue and CollectionValue still occupy 16 bytes but only have 12
> bytes of actual data. This results in a higher memory footprint, which leads
> to higher memory requirements and worse performance. We don't get any benefit
> from the padding since the majority of tuples are not actually aligned in
> memory anyway.
> I did a quick version of the change for StringValue only which improves TPC-H
> performance.
> {noformat}
> Report Generated on 2018-07-30
> Run Description: "b5608264b4552e44eb73ded1e232a8775c3dba6b vs
> f1e401505ac20c0400eec819b9196f7f506fb927"
> Cluster Name: UNKNOWN
> Lab Run Info: UNKNOWN
> Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE ()
> Baseline Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE (2018-07-27)
> +--+---+-++++
> | Workload | File Format | Avg (s) | Delta(Avg) | GeoMean(s) |
> Delta(GeoMean) |
> +--+---+-++++
> | TPCH(10) | parquet / none / none | 2.69| -4.78% | 2.09 |
> -3.11% |
> +--+---+-++++
> +--+--+---++-++++-+---+
> | Workload | Query| File Format | Avg(s) | Base Avg(s) |
> Delta(Avg) | StdDev(%) | Base StdDev(%) | Num Clients | Iters |
> +--+--+---++-++++-+---+
> | TPCH(10) | TPCH-Q22 | parquet / none / none | 0.94 | 0.93|
> +0.75% | 3.37%| 2.84%| 1 | 30|
> | TPCH(10) | TPCH-Q13 | parquet / none / none | 3.32 | 3.32|
> +0.13% | 1.74%| 2.09%| 1 | 30|
> | TPCH(10) | TPCH-Q11 | parquet / none / none | 0.99 | 0.99|
> -0.02% | 3.74%| 3.16%| 1 | 30|
> | TPCH(10) | TPCH-Q5 | parquet / none / none | 2.30 | 2.33|
> -0.96% | 2.15%| 2.45%| 1 | 30|
> | TPCH(10) | TPCH-Q2 | parquet / none / none | 1.55 | 1.57|
> -1.45% | 1.65%| 1.49%| 1 | 30|
> | TPCH(10) | TPCH-Q8 | parquet / none / none | 2.89 | 2.93|
> -1.51% | 2.69%| 1.34%| 1 | 30|
> | TPCH(10) | TPCH-Q9 | parquet / none / none | 5.96 | 6.06|
> -1.63% | 1.34%| 1.82%| 1 | 30|
> | TPCH(10) | TPCH-Q20 | parquet / none / none | 1.58 | 1.61|
> -1.85% | 2.28%| 2.16%| 1 | 30|
> | TPCH(10) | TPCH-Q16 | parquet / none / none | 1.18 | 1.21|
> -2.11% | 3.68%| 4.72%| 1 | 30|
> | TPCH(10) | TPCH-Q3 | parquet / none / none | 2.13 | 2.18|
> -2.31% | 2.09%| 1.92%| 1 | 30|
> | TPCH(10) | TPCH-Q15 | parquet / none / none | 1.86 | 1.90|
> -2.52% | 2.06%| 2.22%| 1 | 30|
> | TPCH(10) | TPCH-Q17 | parquet / none / none | 1.85 | 1.90|
> -2.86% | 10.00% | 8.02%| 1 | 30|
> | TPCH(10) | TPCH-Q10 | parquet / none / none | 2.58 | 2.66|
> -2.93% | 1.68%| 6.49%| 1 | 30|
> | TPCH(10) | TPCH-Q14 | parquet / none / none | 1.37 | 1.42|
> -3.22% | 3.35%| 6.24%| 1 | 30|
> | TPCH(10) | TPCH-Q18 | parquet / none / none | 4.99 | 5.17|
> -3.38% | 1.75%| 3.82%| 1 | 30|
> | TPCH(10) | TPCH-Q6 | parquet / none / none | 0.66 | 0.69|
> -3.73% | 5.04%| 4.12%| 1
[jira] [Comment Edited] (IMPALA-7367) Pack StringValue, CollectionValue and TimestampValue slots
[
https://issues.apache.org/jira/browse/IMPALA-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603589#comment-16603589
]
Pooja Nilangekar edited comment on IMPALA-7367 at 9/4/18 9:25 PM:
--
There is an issue with packing TimestampValue. GCC doesn't pack the class
because its variables are not explicitly declared as packed. So the compiler
complains with the following error for the date_ and time_ attributes:
{code:java}
error: ignoring packed attribute because of unpacked non-POD field
{code}
However, boost::posix_time::time_duration and boost::gregorian::date each
contain single elements of uint64_t and int32_t respectively. I am unaware of
any method to explicitly declare them as packed structures. How should we
handle this? Would it be acceptable to pack StringValue and CollectionValue for
now and create a Jira to track TimestampValue for handling it when boost marks
them as packed?
was (Author: poojanilangekar):
There is an issue with packing TimestampValue. GCC doesn't pack the class
because its variables are not explicitly declared as packed. So the compiler
complains with the following error for the date_ and time_ attributes:
{code:java}
error: ignoring packed attribute because of unpacked non-POD field
{code}
However, boost::posix_time::time_duration and boost::gregorian::date are indeed
packed.This is a known gcc bug
[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60972]. Since the attributes
belong to the boost library, I am unaware of any method to explicitly declare
them as packed structures. How should we handle this? Would it be acceptable to
pack StringValue and CollectionValue for now and create a Jira to track
TimestampValue for when the GCC bug gets resolved?
> Pack StringValue, CollectionValue and TimestampValue slots
> --
>
> Key: IMPALA-7367
> URL: https://issues.apache.org/jira/browse/IMPALA-7367
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Pooja Nilangekar
>Priority: Major
> Labels: perfomance
> Attachments: 0001-WIP.patch
>
>
> This is a follow-on to finish up the work from IMPALA-2789. IMPALA-2789
> didn't actually fully pack the memory layout because StringValue,
> TimestampValue and CollectionValue still occupy 16 bytes but only have 12
> bytes of actual data. This results in a higher memory footprint, which leads
> to higher memory requirements and worse performance. We don't get any benefit
> from the padding since the majority of tuples are not actually aligned in
> memory anyway.
> I did a quick version of the change for StringValue only which improves TPC-H
> performance.
> {noformat}
> Report Generated on 2018-07-30
> Run Description: "b5608264b4552e44eb73ded1e232a8775c3dba6b vs
> f1e401505ac20c0400eec819b9196f7f506fb927"
> Cluster Name: UNKNOWN
> Lab Run Info: UNKNOWN
> Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE ()
> Baseline Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE (2018-07-27)
> +--+---+-++++
> | Workload | File Format | Avg (s) | Delta(Avg) | GeoMean(s) |
> Delta(GeoMean) |
> +--+---+-++++
> | TPCH(10) | parquet / none / none | 2.69| -4.78% | 2.09 |
> -3.11% |
> +--+---+-++++
> +--+--+---++-++++-+---+
> | Workload | Query| File Format | Avg(s) | Base Avg(s) |
> Delta(Avg) | StdDev(%) | Base StdDev(%) | Num Clients | Iters |
> +--+--+---++-++++-+---+
> | TPCH(10) | TPCH-Q22 | parquet / none / none | 0.94 | 0.93|
> +0.75% | 3.37%| 2.84%| 1 | 30|
> | TPCH(10) | TPCH-Q13 | parquet / none / none | 3.32 | 3.32|
> +0.13% | 1.74%| 2.09%| 1 | 30|
> | TPCH(10) | TPCH-Q11 | parquet / none / none | 0.99 | 0.99|
> -0.02% | 3.74%| 3.16%| 1 | 30|
> | TPCH(10) | TPCH-Q5 | parquet / none / none | 2.30 | 2.33|
> -0.96% | 2.15%| 2.45%| 1 | 30|
> | TPCH(10) | TPCH-Q2 | parquet / none / none | 1.55 | 1.57|
> -1.45% | 1.65%| 1.49%| 1 | 30|
> | TPCH(10) | TPCH-Q8 | parquet / none / none | 2.89 | 2.93|
> -1.51% | 2.69%| 1.34%| 1 | 3
[jira] [Commented] (IMPALA-7367) Pack StringValue, CollectionValue and TimestampValue slots
[
https://issues.apache.org/jira/browse/IMPALA-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603589#comment-16603589
]
Pooja Nilangekar commented on IMPALA-7367:
--
There is an issue with packing TimestampValue. GCC doesn't pack the class
because its variables are not explicitly declared as packed. So the compiler
complains with the following error for the date_ and time_ attributes:
{code:java}
error: ignoring packed attribute because of unpacked non-POD field
{code}
However, boost::posix_time::time_duration and boost::gregorian::date are indeed
packed.This is a known gcc bug
[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60972]. Since the attributes
belong to the boost library, I am unaware of any method to explicitly declare
them as packed structures. How should we handle this? Would it be acceptable to
pack StringValue and CollectionValue for now and create a Jira to track
TimestampValue for when the GCC bug gets resolved?
> Pack StringValue, CollectionValue and TimestampValue slots
> --
>
> Key: IMPALA-7367
> URL: https://issues.apache.org/jira/browse/IMPALA-7367
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Pooja Nilangekar
>Priority: Major
> Labels: perfomance
> Attachments: 0001-WIP.patch
>
>
> This is a follow-on to finish up the work from IMPALA-2789. IMPALA-2789
> didn't actually fully pack the memory layout because StringValue,
> TimestampValue and CollectionValue still occupy 16 bytes but only have 12
> bytes of actual data. This results in a higher memory footprint, which leads
> to higher memory requirements and worse performance. We don't get any benefit
> from the padding since the majority of tuples are not actually aligned in
> memory anyway.
> I did a quick version of the change for StringValue only which improves TPC-H
> performance.
> {noformat}
> Report Generated on 2018-07-30
> Run Description: "b5608264b4552e44eb73ded1e232a8775c3dba6b vs
> f1e401505ac20c0400eec819b9196f7f506fb927"
> Cluster Name: UNKNOWN
> Lab Run Info: UNKNOWN
> Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE ()
> Baseline Impala Version: impalad version 3.1.0-SNAPSHOT RELEASE (2018-07-27)
> +--+---+-++++
> | Workload | File Format | Avg (s) | Delta(Avg) | GeoMean(s) |
> Delta(GeoMean) |
> +--+---+-++++
> | TPCH(10) | parquet / none / none | 2.69| -4.78% | 2.09 |
> -3.11% |
> +--+---+-++++
> +--+--+---++-++++-+---+
> | Workload | Query| File Format | Avg(s) | Base Avg(s) |
> Delta(Avg) | StdDev(%) | Base StdDev(%) | Num Clients | Iters |
> +--+--+---++-++++-+---+
> | TPCH(10) | TPCH-Q22 | parquet / none / none | 0.94 | 0.93|
> +0.75% | 3.37%| 2.84%| 1 | 30|
> | TPCH(10) | TPCH-Q13 | parquet / none / none | 3.32 | 3.32|
> +0.13% | 1.74%| 2.09%| 1 | 30|
> | TPCH(10) | TPCH-Q11 | parquet / none / none | 0.99 | 0.99|
> -0.02% | 3.74%| 3.16%| 1 | 30|
> | TPCH(10) | TPCH-Q5 | parquet / none / none | 2.30 | 2.33|
> -0.96% | 2.15%| 2.45%| 1 | 30|
> | TPCH(10) | TPCH-Q2 | parquet / none / none | 1.55 | 1.57|
> -1.45% | 1.65%| 1.49%| 1 | 30|
> | TPCH(10) | TPCH-Q8 | parquet / none / none | 2.89 | 2.93|
> -1.51% | 2.69%| 1.34%| 1 | 30|
> | TPCH(10) | TPCH-Q9 | parquet / none / none | 5.96 | 6.06|
> -1.63% | 1.34%| 1.82%| 1 | 30|
> | TPCH(10) | TPCH-Q20 | parquet / none / none | 1.58 | 1.61|
> -1.85% | 2.28%| 2.16%| 1 | 30|
> | TPCH(10) | TPCH-Q16 | parquet / none / none | 1.18 | 1.21|
> -2.11% | 3.68%| 4.72%| 1 | 30|
> | TPCH(10) | TPCH-Q3 | parquet / none / none | 2.13 | 2.18|
> -2.31% | 2.09%| 1.92%| 1 | 30|
> | TPCH(10) | TPCH-Q15 | parquet / none / none | 1.86 | 1.90|
> -2.52% | 2.06%| 2.22%| 1 | 30|
> | TPCH(10) | TPCH-Q17 | parquet / none / none | 1.85 | 1.90|
> -2.86%
[jira] [Resolved] (IMPALA-7505) impalad webserver hang in getting a lock of QueryExecStatus
[
https://issues.apache.org/jira/browse/IMPALA-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v resolved IMPALA-7505.
---
Resolution: Duplicate
> impalad webserver hang in getting a lock of QueryExecStatus
> ---
>
> Key: IMPALA-7505
> URL: https://issues.apache.org/jira/browse/IMPALA-7505
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.8.0
>Reporter: Chen Wang
>Priority: Major
> Attachments: gdb.out
>
>
> Impalad’s webserver would hang sometimes.
> The following is one of the cases: the webserver threads stuck in getting a
> lock of QueryExecStatus, but I can't find where the lock is acquired in the
> stack. The web requests are sent from the agent of CDH, which is to check the
> activity of impalad.
> Full gdb log is in the attachment.
> {code}
> Thread 116 (Thread 0x7f288f5e1700 (LWP 31062)):
> #0 0x00378780e334 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x0037878095d8 in _L_lock_854 () from /lib64/libpthread.so.0
> #2 0x0037878094a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3 0x008d6eb8 in pthread_mutex_lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:62
> #4 boost::mutex::lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:116
> #5 0x00b7903c in lock_guard (this=0xa7b5800, query_id=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/lock_guard.hpp:38
> #6 impala::ImpalaServer::GetRuntimeProfileStr (this=0xa7b5800, query_id=) at
> /data/impala/be/src/service/impala-server.cc:573
> #7 0x00ba6a8c in
> impala::ImpalaHttpHandler::QueryProfileEncodedHandler (this=0x3f56be0, args=)
> at /data/impala/be/src/service/impala-http-handler.cc:219
> #8 0x00cafe75 in operator() (this=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/function/function_template.hpp:767
> #9 impala::Webserver::RenderUrlWithTemplate (this=) at
> /data/impala/be/src/util/webserver.cc:443
> #10 0x00cb1295 in impala::Webserver::BeginRequestCallback (this=) at
> /data/impala/be/src/util/webserver.cc:414
> #11 0x00cc4850 in handle_request ()
> #12 0x00cc6fcd in process_new_connection ()
> #13 0x00cc765d in worker_thread ()
> #14 0x003787807aa1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0037874e8bcd in clone () from /lib64/libc.so.6
> {code}
> The hang situation appears on impala 2.8.0, but I found that code of
> be/service part hasn’t changed much from 2.8.0 to 2.11.0. so the problem may
> still exists.
> Hope you experts can give me some guidance of finding the root cause, or
> workaround plans to deal with these hang situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7524) Keep frame pointers for generated code
[ https://issues.apache.org/jira/browse/IMPALA-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Ho updated IMPALA-7524: --- Labels: codegen (was: ) > Keep frame pointers for generated code > -- > > Key: IMPALA-7524 > URL: https://issues.apache.org/jira/browse/IMPALA-7524 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.13.0, Impala 3.1.0 >Reporter: Lars Volker >Priority: Major > Labels: codegen > > Generated code does not preserve the frame pointer and thus stack unwinding > does not work when we crash in generated functions. We should preserve the > frame pointers to make debugging easier. Kudu's experience and our own in > IMPALA-4132 suggest that the performance hit will be tolerable (but we still > should do a proper perf evaluation). > Here's Kudu's way of preserving the frame pointers: > [module_builder.cc:294|https://github.com/apache/kudu/blob/eb15beabd2d4d86649a35dcd027e1749cc695866/src/kudu/codegen/module_builder.cc#L294]. > Thanks [~tlipcon] for the suggestion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-6919) Impala 3.1 Doc: Doc the COMMENT ON statements
[ https://issues.apache.org/jira/browse/IMPALA-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-6919. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Impala 3.1 Doc: Doc the COMMENT ON statements > - > > Key: IMPALA-6919 > URL: https://issues.apache.org/jira/browse/IMPALA-6919 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Affects Versions: Impala 2.13.0, Impala 3.1.0 >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc > Fix For: Impala 3.1.0 > > > https://gerrit.cloudera.org/#/c/11370/ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7524) Keep frame pointers for generated code
Lars Volker created IMPALA-7524: --- Summary: Keep frame pointers for generated code Key: IMPALA-7524 URL: https://issues.apache.org/jira/browse/IMPALA-7524 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 2.13.0, Impala 3.1.0 Reporter: Lars Volker Generated code does not preserve the frame pointer and thus stack unwinding does not work when we crash in generated functions. We should preserve the frame pointers to make debugging easier. Kudu's experience and our own in IMPALA-4132 suggest that the performance hit will be tolerable (but we still should do a proper perf evaluation). Here's Kudu's way of preserving the frame pointers: [module_builder.cc:294|https://github.com/apache/kudu/blob/eb15beabd2d4d86649a35dcd027e1749cc695866/src/kudu/codegen/module_builder.cc#L294]. Thanks [~tlipcon] for the suggestion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7348) PlannerTest.testKuduSelectivity failing due to missing Cardinality information
[
https://issues.apache.org/jira/browse/IMPALA-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603236#comment-16603236
]
Philip Zeyliger commented on IMPALA-7348:
-
Saw this again. The two tests were:
org.apache.impala.planner.PlannerTest.testMinMaxRuntimeFilters and
org.apache.impala.planner.PlannerTest.testKudu
Here's the plan differences:
{code}
hash predicates: a.int_col = b.tinyint_col + 1, a.string_col = b.string_col
vs
hash predicates: a.string_col = b.string_col, a.int_col = b.tinyint_col + 1
{code}
and
{code}
predicates: bigint_col IN (NULL), bool_col IN (NULL), double_col IN (NULL),
float_col IN (NULL), smallint_col IN (NULL), string_col IN (NULL), tinyint_col
IN (NULL), id IN (1, NULL)
vs
predicates: id IN (1, NULL), bigint_col IN (NULL), bool_col IN (NULL),
double_col IN (NULL), float_col IN (NULL), smallint_col IN (NULL), string_col
IN (NULL), tinyint_col IN (NULL)
{code}
Curiously, this is all happening only within Kudu. The verbose plans indicate
that cardinality is unavailable, which makes me think that
{{orderConjunctsByCost}} is stable, but we're missing cardinality information.
> PlannerTest.testKuduSelectivity failing due to missing Cardinality information
> --
>
> Key: IMPALA-7348
> URL: https://issues.apache.org/jira/browse/IMPALA-7348
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Reporter: nithya
>Assignee: Vuk Ercegovac
>Priority: Blocker
> Labels: broken-build
>
> PlannerTest.testKuduSelectivity failed in the recent run. It is an assertion
> failure to unavailable cardinality information.
> Assertion failure as follows
> {code:java}
> Actual does not match expected result:
> F00:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-reservation=0B
> |
> 00:SCAN KUDU [functional_kudu.zipcode_incomes]
> kudu predicates: id = '860US00601'
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=68B cardinality=unavailable
> ^
> Expected:
> F00:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-reservation=0B
> |
> 00:SCAN KUDU [functional_kudu.zipcode_incomes]
> kudu predicates: id = '860US00601'
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=124B cardinality=1 {code}
> Verbose plan
> {code:java}
> Verbose plan:
> F00:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-reservation=0B
> |
> 00:SCAN KUDU [functional_kudu.zipcode_incomes]
> kudu predicates: id = '860US00601'
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=68B cardinality=unavailable
> Section DISTRIBUTEDPLAN of query:
> select * from functional_kudu.zipcode_incomes where id = '860US00601'
> Actual does not match expected result:
> F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-reservation=0B
> |
> 01:EXCHANGE [UNPARTITIONED]
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=68B cardinality=unavailable
> ^
> F00:PLAN FRAGMENT [RANDOM] hosts=3 instances=3
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=01, UNPARTITIONED]
> | mem-estimate=0B mem-reservation=0B
> 00:SCAN KUDU [functional_kudu.zipcode_incomes]
> kudu predicates: id = '860US00601'
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=68B cardinality=unavailable
> Expected:
> F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-reservation=0B
> |
> 01:EXCHANGE [UNPARTITIONED]
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=124B cardinality=1
> F00:PLAN FRAGMENT [RANDOM] hosts=3 instances=3
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> DATASTREAM SINK [FRAGMENT=F01, EXCHANGE=01, UNPARTITIONED]
> | mem-estimate=0B mem-reservation=0B
> 00:SCAN KUDU [functional_kudu.zipcode_incomes]
> kudu predicates: id = '860US00601'
> mem-estimate=0B mem-reservation=0B
> tuple-ids=0 row-size=124B cardinality=1
> Verbose plan:
> F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> Per-Host Resources: mem-estimate=0B mem-reservation=0B
> PLAN-ROOT SINK
> | mem-estimate=0B mem-r
[jira] [Created] (IMPALA-7523) Planner Test failing with "Failed to assign regions to servers after 60000 millis."
Philip Zeyliger created IMPALA-7523:
---
Summary: Planner Test failing with "Failed to assign regions to
servers after 6 millis."
Key: IMPALA-7523
URL: https://issues.apache.org/jira/browse/IMPALA-7523
Project: IMPALA
Issue Type: Task
Components: Frontend
Reporter: Philip Zeyliger
I've seen
{{org.apache.impala.planner.PlannerTest.org.apache.impala.planner.PlannerTest}}
fail with the following trace:
{code}
java.lang.IllegalStateException: Failed to assign regions to servers after
6 millis.
at
org.apache.impala.datagenerator.HBaseTestDataRegionAssignment.performAssignment(HBaseTestDataRegionAssignment.java:153)
at
org.apache.impala.planner.PlannerTestBase.setUp(PlannerTestBase.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{code}
I think we've seen it before as indicated in IMPALA-7061.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-2200) [Cloudera][ODBC] (10000) General error: Unexpected exception has been caught.
[ https://issues.apache.org/jira/browse/IMPALA-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16603186#comment-16603186 ] John Kew commented on IMPALA-2200: -- That capability I mentioned is currently undocumented on the Tableau side ( fixing that ), but it suppresses all prepared queries for the data source and we use it with a number of hive-based datasources. "CAP_ODBC_SUPPRESS_PREPARED_QUERY_FOR_NON_COMMAND_QUERIES" > [Cloudera][ODBC] (1) General error: Unexpected exception has been caught. > - > > Key: IMPALA-2200 > URL: https://issues.apache.org/jira/browse/IMPALA-2200 > Project: IMPALA > Issue Type: Bug > Components: Clients >Affects Versions: Impala 2.2 > Environment: Server: > OS: CentOS 6.6 > CDH 5.4.4 cluster with Cloudera manager - > Version: Cloudera Express 5.4.3 (#258 built by jenkins on 20150625-2046 git: > 1139ffb081360fbbb1be8a19a87ca3c52ee4b1cf) > Impala: impalad version 2.2.0-cdh5.4.4 RELEASE (build > a13d3c6b203e79a284b509df821bffbe229e6dc3) > Client: > OS: Windows 7/8 > client app: Tableau Desktop > Latest, at the moment, Impala-ODBC driver - > http://www.cloudera.com/content/cloudera/en/downloads/connectors/impala/odbc/impala-odbc-v2-5-29.html > Tableau desktop: version 8/9 >Reporter: Boyan Bonev >Assignee: Syed A. Hashmi >Priority: Minor > Labels: impala, odbc > Attachments: SimbaImpalaODBC_driver.log > > > Hi, > We are have a CDH 5.4.4 cluster and use Impala for add-hoc data analysis. We > also use Tableau for data visualization. The Tableau connects to Impala using > your ODBC driver. We experience several issues, but most important one is > that sometimes (1 out of 10 queries) our queries fail for unknown issue. When > we retry the issues is gone till the next occurrence. There is no info in the > server and almost no info in the ODBC client log (see attachment). Actually > the the only message that the client shows is logged in the ODBC log: > Aug 10 14:02:43 ERROR 8284 Statement::SQLPrepareW: [Cloudera][ODBC] (1) > General error: Unexpected exception has been caught. > Judging by this we suspect that this might be an ODBC driver issue in the > client in the prepared statement logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-6798) New command for showing User Level Privileges
[ https://issues.apache.org/jira/browse/IMPALA-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holley resolved IMPALA-6798. - Resolution: Duplicate > New command for showing User Level Privileges > - > > Key: IMPALA-6798 > URL: https://issues.apache.org/jira/browse/IMPALA-6798 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Reporter: Adam Holley >Priority: Major > > New statement for showing user level privileges > SHOW GRANT USER -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7522) milliseconds_add() can lead to overflow / DCHECK
[
https://issues.apache.org/jira/browse/IMPALA-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer updated IMPALA-7522:
Component/s: Backend
> milliseconds_add() can lead to overflow / DCHECK
>
>
> Key: IMPALA-7522
> URL: https://issues.apache.org/jira/browse/IMPALA-7522
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Reporter: Csaba Ringhofer
>Priority: Major
> Labels: correctness, timestamp
>
> select milliseconds_add("1970-01-01", -10);
> release build: result = 2237-09-01 05:47:53.709551616 (should be 1653-02-10
> 06:13:20)
> debug build: timestamp-functions-ir.cc:740] Check failed: result_value <
> input_value (2237-09-01 05:47:53.709551616 vs. 1970-01-01 00:00:00)
> seconds/microseconds_add work correctly with the same timestamp
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7522) milliseconds_add() can lead to overflow / DCHECK
[
https://issues.apache.org/jira/browse/IMPALA-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer updated IMPALA-7522:
Labels: correctness timestamp (was: )
> milliseconds_add() can lead to overflow / DCHECK
>
>
> Key: IMPALA-7522
> URL: https://issues.apache.org/jira/browse/IMPALA-7522
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Reporter: Csaba Ringhofer
>Priority: Major
> Labels: correctness, timestamp
>
> select milliseconds_add("1970-01-01", -10);
> release build: result = 2237-09-01 05:47:53.709551616 (should be 1653-02-10
> 06:13:20)
> debug build: timestamp-functions-ir.cc:740] Check failed: result_value <
> input_value (2237-09-01 05:47:53.709551616 vs. 1970-01-01 00:00:00)
> seconds/microseconds_add work correctly with the same timestamp
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7522) milliseconds_add() can lead overflow / DCHECK
[
https://issues.apache.org/jira/browse/IMPALA-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer updated IMPALA-7522:
Issue Type: Bug (was: Improvement)
> milliseconds_add() can lead overflow / DCHECK
> -
>
> Key: IMPALA-7522
> URL: https://issues.apache.org/jira/browse/IMPALA-7522
> Project: IMPALA
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Major
>
> select milliseconds_add("1970-01-01", -10);
> release build: result = 2237-09-01 05:47:53.709551616 (should be 1653-02-10
> 06:13:20)
> debug build: timestamp-functions-ir.cc:740] Check failed: result_value <
> input_value (2237-09-01 05:47:53.709551616 vs. 1970-01-01 00:00:00)
> seconds/microseconds_add work correctly with the same timestamp
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7522) milliseconds_add() can lead overflow / DCHECK
Csaba Ringhofer created IMPALA-7522:
---
Summary: milliseconds_add() can lead overflow / DCHECK
Key: IMPALA-7522
URL: https://issues.apache.org/jira/browse/IMPALA-7522
Project: IMPALA
Issue Type: Improvement
Reporter: Csaba Ringhofer
select milliseconds_add("1970-01-01", -10);
release build: result = 2237-09-01 05:47:53.709551616 (should be 1653-02-10
06:13:20)
debug build: timestamp-functions-ir.cc:740] Check failed: result_value <
input_value (2237-09-01 05:47:53.709551616 vs. 1970-01-01 00:00:00)
seconds/microseconds_add work correctly with the same timestamp
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7522) milliseconds_add() can lead to overflow / DCHECK
[
https://issues.apache.org/jira/browse/IMPALA-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer updated IMPALA-7522:
Summary: milliseconds_add() can lead to overflow / DCHECK (was:
milliseconds_add() can lead overflow / DCHECK)
> milliseconds_add() can lead to overflow / DCHECK
>
>
> Key: IMPALA-7522
> URL: https://issues.apache.org/jira/browse/IMPALA-7522
> Project: IMPALA
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Major
>
> select milliseconds_add("1970-01-01", -10);
> release build: result = 2237-09-01 05:47:53.709551616 (should be 1653-02-10
> 06:13:20)
> debug build: timestamp-functions-ir.cc:740] Check failed: result_value <
> input_value (2237-09-01 05:47:53.709551616 vs. 1970-01-01 00:00:00)
> seconds/microseconds_add work correctly with the same timestamp
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
