[jira] [Resolved] (IMPALA-8052) Fail to run ExprTest.TimestampFunctions
[
https://issues.apache.org/jira/browse/IMPALA-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-8052.
---
Resolution: Duplicate
> Fail to run ExprTest.TimestampFunctions
> ---
>
> Key: IMPALA-8052
> URL: https://issues.apache.org/jira/browse/IMPALA-8052
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 3.1.0
>Reporter: Quanlong Huang
>Priority: Major
>
> Encountered the following test errors from ExprTest.TimestampFunctions:
> {code:java}
> [ RUN ] ExprTest.TimestampFunctions
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: -28800
> Expected: expected_result
> Which is: 0
> unix_timestamp(cast('1969-12-31 16:00:00' as timestamp))
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: -28800
> Expected: expected_result
> Which is: 0
> unix_timestamp('1969-12-31 16:00:00')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: -28800
> Expected: expected_result
> Which is: 0
> unix_timestamp('1969-12-31 16:00:00', '-MM-dd HH:mm:ss')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: 0
> Expected: expected_result
> Which is: 28800
> unix_timestamp('1970-01-01', '-MM-dd')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: 0
> Expected: expected_result
> Which is: 28800
> unix_timestamp('1970-01-01 10:10:10', '-MM-dd')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:559: Failure
> Value of: ConvertValue(result)
> Actual: -28800
> Expected: expected_result
> Which is: 0
> unix_timestamp('1969-12-31 16:00:00 extra text', '-MM-dd HH:mm:ss')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> cast(cast(0 as timestamp) as string)
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> cast(cast(0 as timestamp) as string)
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> from_unixtime(0)
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> from_unixtime(cast(0 as bigint))
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> from_unixtime(0, '-MM-dd HH:mm:ss')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 00:00:00"
> Expected: expected_result
> Which is: "1969-12-31 16:00:00"
> from_unixtime(cast(0 as bigint), '-MM-dd HH:mm:ss')
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:289: Failure
> Value of: GetValue(expr, TYPE_STRING)
> Actual: "1970-01-01 08:00:00"
> Expected: expected_result
> Which is: "1970-01-01 00:00:00"
> cast(to_timestamp(28800) as string)
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:445: Failure
> Expected: (value) <= (end), actual: 1546742379 vs 1546713579
> Google Test trace:
> /tmp/jenkins/workspace/impala-hulu/be/src/exprs/expr-test.cc:6572:
> [ FAILED ] ExprTest.TimestampFunctions (6409 ms)
> [ RUN ] ExprTest.ConditionalFunctions
> [ OK ] ExprTest.ConditionalFunctions (1623 ms)
> [ RUN ] ExprTest.ConditionalFunctionIsTrue
> [ OK ] ExprTest.ConditionalFunctionIsTrue (105 ms)
> [ RUN ] ExprTest.ConditionalFunctionIsFalse
> [ OK ] ExprTest.ConditionalFunctionIsFalse (105 ms)
> [ RUN ] ExprTest.ConditionalFunctionIsNotTrue
> [ OK ] ExprTest.ConditionalFunctionIsNotTrue (105 ms)
> [ RUN ] ExprTest.ConditionalFunctionIsNotFalse
> [ OK ] ExprTest.ConditionalFunctionIsNotFalse (102 ms)
> [ RUN ] ExprTest.ResultsLayoutTest
> [ OK ] ExprTest.ResultsLayoutTest (0 ms)
> [ RUN ] ExprTest.DecimalFunctions
> [ OK ] ExprTest.DecimalFunctions (2990 ms)
> [ RUN ] ExprTest.DecimalOverflowCastsDecimalV1
> [ OK ] ExprTest.DecimalOverflowCastsDecimalV1 (357 ms)
> [ RUN ] ExprTest.DecimalOverflowCa
[jira] [Created] (IMPALA-8054) Implicit cast fails with {const INT} BETWEEN FLOAT and INT
Greg Rahn created IMPALA-8054:
-
Summary: Implicit cast fails with {const INT} BETWEEN FLOAT and INT
Key: IMPALA-8054
URL: https://issues.apache.org/jira/browse/IMPALA-8054
Project: IMPALA
Issue Type: Bug
Components: Frontend
Affects Versions: Impala 3.2.0
Reporter: Greg Rahn
Assignee: Paul Rogers
In the following query the literal number 10 needs to be compared to two
different types: INT and FLOAT, but Impala fails to make the implicit cast for
the FLOAD.
The predicates should be
{noformat}
predicates: (cast(10 as float) >= col4) AND (10 <= col3)
{noformat}
*Test case:*
{noformat}
sql> describe tab4
+--++-+
| name | type | comment |
+--++-+
| pk | int| |
| col0 | int| |
| col1 | float | |
| col2 | string | |
| col3 | int| |
| col4 | float | |
| col5 | string | |
+--++-+
sql> SELECT col0 FROM tab4 WHERE 10 BETWEEN col4 AND col3;
ERROR: IllegalStateException: child 0 type: FLOAT child 1 type: DOUBLE
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-8026) Actual row counts for nested loop join are way too high while the query is executing
[
https://issues.apache.org/jira/browse/IMPALA-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-8026.
---
Resolution: Fixed
Fix Version/s: Impala 3.2.0
> Actual row counts for nested loop join are way too high while the query is
> executing
>
>
> Key: IMPALA-8026
> URL: https://issues.apache.org/jira/browse/IMPALA-8026
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Paul Rogers
>Assignee: Tim Armstrong
>Priority: Major
> Fix For: Impala 3.2.0
>
>
> Consider this extract from a query plan:
> {noformat}
> Operator #Rows Est. #Rows
> --
> …
> | 10:HASH JOIN 9.53M 18.14K
> | |--19:EXCHANGE 1 1
> | | 00:SCAN HDFS1 1
> | 06:NESTED LOOP JOIN4.88B 863.84K
> | |--18:EXCHANGE 1 1
> | | 04:SCAN HDFS1 1
> | 05:HASH JOIN 9.53M 863.84K
> {noformat}
> If the above is to be believed, the 06 nested loop join produced 5 billion
> rows. But, the actual number is far too huge for that: joining 1 row with 10
> million rows cannot produce 500 times that number of rows.
> It appears that the nested loop join actually processed and returned the 9.5
> million rows, since that is the same number produced by the 10 hash join
> which joins a single row with the output of the nested loop join.
> Because this same bogus result appears across multiple plans, it is likely
> that the actual number is completely wrong and bears no relation to the
> number of rows actually returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-7625) test_web_pages.py backend tests are failing
[
https://issues.apache.org/jira/browse/IMPALA-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar resolved IMPALA-7625.
--
Resolution: Fixed
Fix Version/s: Impala 3.2.0
> test_web_pages.py backend tests are failing
> ---
>
> Key: IMPALA-7625
> URL: https://issues.apache.org/jira/browse/IMPALA-7625
> Project: IMPALA
> Issue Type: Test
> Components: Infrastructure
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
> Fix For: Impala 3.2.0
>
>
> While working on IMPALA-6249, we found that the tests under
> {{webserver/test_web_pages.py}} are not being run by Jenkins. We re-enabled
> the tests, however, a few of the backend specific tests are failing.
> IMPALA-6249 disabled these tests. This JIRA is to follow up on these tests
> and fix them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-8055) run-tests.py reports tests as passed even if the did not
Paul Rogers created IMPALA-8055:
---
Summary: run-tests.py reports tests as passed even if the did not
Key: IMPALA-8055
URL: https://issues.apache.org/jira/browse/IMPALA-8055
Project: IMPALA
Issue Type: Bug
Components: Infrastructure
Affects Versions: Impala 3.1.0
Reporter: Paul Rogers
Been mucking about with the EXPLAIN output format which required rebasing a
bunch of tests on the new format. PlannerTest is fine: it clearly fails when
the expected ".test" files don't match the new "actual" files.
When run on Jenkins in "pre-review" mode, the build does fail if a Python
end-to-end test fails. But, the job seems to give up at that point, not running
other tests and finding more problems. (There were three separate test cases
that needed fixing; took multiple runs to find them.)
When run on my dev box, I get the following (highly abbreviated) output:
{noformat}
'| in pipelines: 00(GETNEXT)' != '| row-size=402B cardinality=5.76M'
...
[gw3] PASSED
metadata/test_explain.py::TestExplain::test_explain_level0[protocol: beeswax |
exec_option: {'batch_size': 0, 'num_nodes': 0,
'disable_codegen_rows_threshold': 0, 'disable_codegen': False,
'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
0} | table_format: text/none]
...
6 passed in 68.63 seconds =
{noformat}
I've learned that "passed" means "maybe failed" and to go back and inspect the
actual output to figure out if the test did, indeed, fail. I suspect "passed"
means "didn't crash" rather than "tests worked."
Would be very helpful to plumb the failure through to the summary line so it
said "3 passed, 3 failed" or whatever. Would be a huge time-saver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
