[jira] [Commented] (TRAFODION-2109) Load with log error rows returns the following error at times
[ https://issues.apache.org/jira/browse/TRAFODION-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376315#comment-15376315 ] Selvaganesan Govindarajan commented on TRAFODION-2109: -- Analysis of the issue reveals the following: One of the ESPs returned the internal error below while writing the error log record in hdfs. data_ = 0x7f8a38756d70 "\njava.nio.channels.ClosedChannelException\n org.apache.hadoop.hdfs.DFSOutputStream.checkClosed(DFSOutputStream.java:1635)\n org.apache.hadoop.fs.FSOutputSummer.write(FSOutputSummer.java:104)\n org.apache.hadoop.fs.FSDataOutputStream$PositionCache.write(FSDataOutputStream.java:58)\n java.io.DataOutputStream.write(DataOutputStream.java:107)\n java.io.FilterOutputStream.write(FilterOutputStream.java:97)\n org.trafodion.sql.HiveClient.hdfsWrite(HiveClient.java:278)\n" Hdfs scan returned an error -8413. This error row along with the error information is written to error log file in hdfs. But the writing to the error log file returned an error as shown in the above stack trace. This ESP is supposed to core with the asserting message shown below: ex_assert((retcode == HBASE_ACCESS_SUCCESS), "Error while writing the log file"); I have seen earlier ex_assert is ignored in release mode. Tried with ABORT_ON_ERROR=2034 in $MY_SQROOT/etc/ms.env.. This setting dumped the core for the ESP process or error -8413 though ABORT_ON_ERROR is set to 2034 because the error is thrown due to ex_assert. I think though it didn’t dump core earlier, it triggered error 2034. But, the actual error message was lost. > Load with log error rows returns the following error at times > - > > Key: TRAFODION-2109 > URL: https://issues.apache.org/jira/browse/TRAFODION-2109 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 1.3-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > load with log error rows into > select * from hive.hive. > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > --- 0 row(s) loaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-2109) Load with log error rows returns the following error at times
[ https://issues.apache.org/jira/browse/TRAFODION-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2109: Assignee: Selvaganesan Govindarajan > Load with log error rows returns the following error at times > - > > Key: TRAFODION-2109 > URL: https://issues.apache.org/jira/browse/TRAFODION-2109 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 1.3-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > load with log error rows into > select * from hive.hive. > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating > with server process $Z021FS0:425. > > --- 0 row(s) loaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2109) Load with log error rows returns the following error at times
Selvaganesan Govindarajan created TRAFODION-2109: Summary: Load with log error rows returns the following error at times Key: TRAFODION-2109 URL: https://issues.apache.org/jira/browse/TRAFODION-2109 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 1.3-incubating Reporter: Selvaganesan Govindarajan Fix For: 2.1-incubating load with log error rows into select * from hive.hive. *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating with server process $Z021FS0:425. *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating with server process $Z021FS0:425. *** ERROR[2034] $Z0014JQ:5192: Operating system error 201 while communicating with server process $Z021FS0:425. --- 0 row(s) loaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1673) Implement the WITH clause in Trafodion SQL for simple use cases
[
https://issues.apache.org/jira/browse/TRAFODION-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15376157#comment-15376157
]
ASF GitHub Bot commented on TRAFODION-1673:
---
Github user traflm commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/577#discussion_r70736959
--- Diff: core/sql/parser/sqlparser.y ---
@@ -14684,6 +14759,11 @@ optional_limit_spec : TOK_LIMIT
NUMERIC_LITERAL_EXACT_NO_SCALE
dml_statement : dml_query { $$ = $1; }
+ | with_clause_list dml_query
--- End diff --
I found a way to avoid the reduce/shift and reduce/reduce error by add
with_clause down to the underlying rules of non_join_query_expression, instead
of add it at same level of non_join_query_expression. non_join_query_expression
can represent many different styles of query expression, including utilities,
which we don't want a with_clause as prefix, so in the underlying rules, only
add with_clause before those SELECT syntax, and it solve the problem.
And it seems if use redundant rule explicitly (looks annoying) , we can
avoid the error.
For example:
A : b | c
is better to change to
A : b
A : c
I am still trying to understand this.
I checked with PostgreSQL parser, they are doing similar things, comments
from postgresql parser:
* This rule parses the equivalent of the standard's .
* The duplicative productions are annoying, but hard to get rid of without
* creating shift/reduce conflicts.
> Implement the WITH clause in Trafodion SQL for simple use cases
> ---
>
> Key: TRAFODION-1673
> URL: https://issues.apache.org/jira/browse/TRAFODION-1673
> Project: Apache Trafodion
> Issue Type: New Feature
> Components: sql-cmp
>Reporter: Hans Zeller
>Assignee: liu ming
>
> We keep running into queries that use a WITH clause to define a temporary
> view that can be used once or multiple times in a FROM clause in the query.
> For non-recursive queries, the WITH clause could probably be handled very
> similar to a view. When it is defined, we create an in-memory view
> descriptor, containing the name and the definition. When it is used in a FROM
> clause, we could go through a code path similar to that of a view - bind the
> (temporary) view text and substitute it in the query. The fix could probably
> be handled entirely in the binder.
> This JIRA is *not* about recursive queries, those would require a lot more
> effort, involving many components in addition to the binder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TRAFODION-1843) Allow USER option(s) to be defined as defaults in a table column definition
[ https://issues.apache.org/jira/browse/TRAFODION-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sharma reassigned TRAFODION-1843: --- Assignee: Anoop Sharma > Allow USER option(s) to be defined as defaults in a table column definition > --- > > Key: TRAFODION-1843 > URL: https://issues.apache.org/jira/browse/TRAFODION-1843 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmu >Reporter: Roberta Marton >Assignee: Anoop Sharma > > SQL ANSI allows you to specify: USER, CURRENT_USER, and SESSION_USER as > default options associated with the when creating a column > definition for a table. Trafodion should support similar functionality. > USER and SYSTEM_USER are semantically the same and irepresents the value of > the current authorization identifier. > SESSION_USER is the values of the SQL session authorization identifier > Support for USER, CURRENT_USER, and SESSION_USER exist in the code and can be > used, for example, in insert statements. > All user values should be returned as a varchar 128 to match the current > implementation. > ANSI also support a SYSTEM_USER option. The SYSTEM_USER is an implementation > defined value that represents the operating system user related to the > process running the request. At this time, there are no plans to support the > SYSTEM_USER. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2108) Allow multiple, different OLAP window specifications in a SELECT
[
https://issues.apache.org/jira/browse/TRAFODION-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hans Zeller updated TRAFODION-2108:
---
Description:
Trafodion supports OLAP functions with a window specification, like this:
{noformat}
select *, sum(b) over(partition by a order by b) x
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
It also allows multiple such functions, as long as they all use the same window
specification:
{noformat}
select *, sum(b) over(partition by a order by b) x,
max(b) over(partition by a order by b) y
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
However, if we use different window specifications in the same SELECT, we get
this error:
{noformat}
select *, sum(b) over(partition by a order by b) x,
max(b) over(partition by b order by a) z
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
*** ERROR[4340] All Window Functions within a query must have
the same window partition clause and window order clause.
{noformat}
It would be nice if we could transparently rewrite this into the following,
supported syntax:
{noformat}
select *, max(b) over(partition by b order by a) z
from (select *, sum(b) over(partition by a order by b) x
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c));
{noformat}
We could also do some optimizations, but that could come later (and would be a
separate JIRA).
was:
Trafodion supports OLAP functions with a window specification, like this:
{noformat}
select *, sum(b) over(partition by a order by b)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
It also allows multiple such functions, as long as they all use the same window
specification:
{noformat}
select *, sum(b) over(partition by a order by b),
max(b) over(partition by a order by b)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
However, if we use different window specifications in the same SELECT, we get
this error:
{noformat}
select *, sum(b) over(partition by a order by b),
max(b) over(partition by b order by a)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
*** ERROR[4340] All Window Functions within a query must have
the same window partition clause and window order clause.
{noformat}
It would be nice if we could transparently rewrite this into the following,
supported syntax:
{noformat}
select *, max(b) over(partition by b order by a) z
from (select *, sum(b) over(partition by a order by b) x
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c));
{noformat}
We could also do some optimizations, but that could come later (and would be a
separate JIRA).
> Allow multiple, different OLAP window specifications in a SELECT
>
>
> Key: TRAFODION-2108
> URL: https://issues.apache.org/jira/browse/TRAFODION-2108
> Project: Apache Trafodion
> Issue Type: New Feature
> Components: sql-cmp
>Affects Versions: 1.3-incubating
> Environment: Any
>Reporter: Hans Zeller
>
> Trafodion supports OLAP functions with a window specification, like this:
> {noformat}
> select *, sum(b) over(partition by a order by b) x
> from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
> {noformat}
> It also allows multiple such functions, as long as they all use the same
> window specification:
> {noformat}
> select *, sum(b) over(partition by a order by b) x,
> max(b) over(partition by a order by b) y
> from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
> {noformat}
> However, if we use different window specifications in the same SELECT, we get
> this error:
> {noformat}
> select *, sum(b) over(partition by a order by b) x,
> max(b) over(partition by b order by a) z
> from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
> *** ERROR[4340] All Window Functions within a query must have
> the same window partition clause and window order clause.
> {noformat}
> It would be nice if we could transparently rewrite this into the following,
> supported syntax:
> {noformat}
> select *, max(b) over(partition by b order by a) z
> from (select *, sum(b) over(partition by a order by b) x
> from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c));
> {noformat}
> We could also do some optimizations, but that could come later (and would be
> a separate JIRA).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-2108) Allow multiple, different OLAP window specifications in a SELECT
Hans Zeller created TRAFODION-2108:
--
Summary: Allow multiple, different OLAP window specifications in a
SELECT
Key: TRAFODION-2108
URL: https://issues.apache.org/jira/browse/TRAFODION-2108
Project: Apache Trafodion
Issue Type: New Feature
Components: sql-cmp
Affects Versions: 1.3-incubating
Environment: Any
Reporter: Hans Zeller
Trafodion supports OLAP functions with a window specification, like this:
{noformat}
select *, sum(b) over(partition by a order by b)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
It also allows multiple such functions, as long as they all use the same window
specification:
{noformat}
select *, sum(b) over(partition by a order by b),
max(b) over(partition by a order by b)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
{noformat}
However, if we use different window specifications in the same SELECT, we get
this error:
{noformat}
select *, sum(b) over(partition by a order by b),
max(b) over(partition by b order by a)
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c);
*** ERROR[4340] All Window Functions within a query must have
the same window partition clause and window order clause.
{noformat}
It would be nice if we could transparently rewrite this into the following,
supported syntax:
{noformat}
select *, max(b) over(partition by b order by a) z
from (select *, sum(b) over(partition by a order by b) x
from (values (1,1,1), (1,2,2), (2,1,3), (2,2,4)) T(a,b,c));
{noformat}
We could also do some optimizations, but that could come later (and would be a
separate JIRA).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TRAFODION-1673) Implement the WITH clause in Trafodion SQL for simple use cases
[
https://issues.apache.org/jira/browse/TRAFODION-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15375270#comment-15375270
]
ASF GitHub Bot commented on TRAFODION-1673:
---
Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/577#discussion_r70656018
--- Diff: core/sql/parser/sqlparser.y ---
@@ -14684,6 +14759,11 @@ optional_limit_spec : TOK_LIMIT
NUMERIC_LITERAL_EXACT_NO_SCALE
dml_statement : dml_query { $$ = $1; }
+ | with_clause_list dml_query
--- End diff --
Yes, I got a similar result. I tried this:
query_expression : with_clause non_join_query_expression
| non_join_query_expression
That gives me three additional reduce/reduce conflicts which I don't
understand. Here are two of them:
State 1941
1870 query_expression: with_clause non_join_query_expression .
1871 | non_join_query_expression .
TOK_EXCEPT reduce using rule 1870 (query_expression)
TOK_EXCEPT [reduce using rule 1871 (query_expression)]
TOK_UNION reduce using rule 1870 (query_expression)
TOK_UNION [reduce using rule 1871 (query_expression)]
$defaultreduce using rule 1870 (query_expression)
I also tried this:
query_expression : optional_with_clause non_join_query_expression
That doesn't cause additional reduce/reduce conflicts, but we get a very
large number of additional shift/reduce conflicts, something in the
neighborhood of 50-100.
If we can't get the "correct" parser rules to work, then maybe we can stick
with the approach you chose (assuming it accepts all the valid WITH clauses)
and handle any illegal syntax in the semantic actions.
> Implement the WITH clause in Trafodion SQL for simple use cases
> ---
>
> Key: TRAFODION-1673
> URL: https://issues.apache.org/jira/browse/TRAFODION-1673
> Project: Apache Trafodion
> Issue Type: New Feature
> Components: sql-cmp
>Reporter: Hans Zeller
>Assignee: liu ming
>
> We keep running into queries that use a WITH clause to define a temporary
> view that can be used once or multiple times in a FROM clause in the query.
> For non-recursive queries, the WITH clause could probably be handled very
> similar to a view. When it is defined, we create an in-memory view
> descriptor, containing the name and the definition. When it is used in a FROM
> clause, we could go through a code path similar to that of a view - bind the
> (temporary) view text and substitute it in the query. The fix could probably
> be handled entirely in the binder.
> This JIRA is *not* about recursive queries, those would require a lot more
> effort, involving many components in addition to the binder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TRAFODION-2106) to_char() can't compare with one date
[ https://issues.apache.org/jira/browse/TRAFODION-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sharma reassigned TRAFODION-2106: --- Assignee: Anoop Sharma > to_char() can't compare with one date > - > > Key: TRAFODION-2106 > URL: https://issues.apache.org/jira/browse/TRAFODION-2106 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: any >Reporter: Joshua Liu >Assignee: Anoop Sharma > > 1.Create one table josh_test > CREATE TABLE TRAFODION.SEABASE.JOSH_TEST > ( > APPDATE VARCHAR(8) CHARACTER SET ISO88591 COLLATE > DEFAULT DEFAULT NULL SERIALIZED > , NAME VARCHAR(10) CHARACTER SET ISO88591 > COLLATE > DEFAULT DEFAULT NULL SERIALIZED > ) > ; > Here appdate is of varchar(8) type > 2.Insert some values into the table > SQL>select * from josh_test; > APPDATE NAME > -- > 20140101 josh > 20140102 jason > 20140821 James > 20140303 Tom > 20150209 Axia > 20150812 Jerry > 20161010 Hong > 20160802 Alex > 3.Try to test to_char: > SQL>select to_date(appdate, 'MMDD'), name from josh_test; > (EXPR) NAME > -- -- > 2014-01-01 josh > 2014-01-02 jason > 2014-08-21 James > 2014-03-03 Tom > 2015-02-09 Axia > 2015-08-12 Jerry > 2016-10-10 Hong > 2016-08-02 Alex > --- 8 row(s) selected. > Here we can see that to_char seems worked. > 4.Try to run another query > select * from josh_test where to_date(appdate, 'MMDD') > date > '2015-01-01'; > but failed: > *** ERROR[4041] Type CHAR(8) cannot be compared with type DATE. [2016-07-12 > 10:20:12] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1673) Implement the WITH clause in Trafodion SQL for simple use cases
[
https://issues.apache.org/jira/browse/TRAFODION-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374956#comment-15374956
]
ASF GitHub Bot commented on TRAFODION-1673:
---
Github user traflm commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/577#discussion_r70620967
--- Diff: core/sql/parser/sqlparser.y ---
@@ -14684,6 +14759,11 @@ optional_limit_spec : TOK_LIMIT
NUMERIC_LITERAL_EXACT_NO_SCALE
dml_statement : dml_query { $$ = $1; }
+ | with_clause_list dml_query
--- End diff --
hi, Hans, Dave,
the current change doesn't get higher number of conflicts, it is still
73/12, but if I tried to move the rule into query_expression, it will increase
the shift/reduce conflicts, I still cannot find a good way to write a correct
syntax. It is rather difficult to find the root cause of shift/reduce conflict
> Implement the WITH clause in Trafodion SQL for simple use cases
> ---
>
> Key: TRAFODION-1673
> URL: https://issues.apache.org/jira/browse/TRAFODION-1673
> Project: Apache Trafodion
> Issue Type: New Feature
> Components: sql-cmp
>Reporter: Hans Zeller
>Assignee: liu ming
>
> We keep running into queries that use a WITH clause to define a temporary
> view that can be used once or multiple times in a FROM clause in the query.
> For non-recursive queries, the WITH clause could probably be handled very
> similar to a view. When it is defined, we create an in-memory view
> descriptor, containing the name and the definition. When it is used in a FROM
> clause, we could go through a code path similar to that of a view - bind the
> (temporary) view text and substitute it in the query. The fix could probably
> be handled entirely in the binder.
> This JIRA is *not* about recursive queries, those would require a lot more
> effort, involving many components in addition to the binder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TRAFODION-2096) create all tpcds hive external tables from install_local_hadoop
[ https://issues.apache.org/jira/browse/TRAFODION-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming resolved TRAFODION-2096. - Resolution: Fixed Fix Version/s: 2.1-incubating > create all tpcds hive external tables from install_local_hadoop > --- > > Key: TRAFODION-2096 > URL: https://issues.apache.org/jira/browse/TRAFODION-2096 > Project: Apache Trafodion > Issue Type: Improvement >Reporter: liu ming >Assignee: liu ming >Priority: Minor > Fix For: 2.1-incubating > > > store_returns > catalog_sales > catalog_returns > web_sales > web_returns > inventory > call_center > catalog_page > web_site > Web_page > warehouse > income_band > reason > ship_mode > These tables were used by TPCDS queries, it will help to automatically > install them in a dev environment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
