[jira] [Created] (IMPALA-7272) impalad crash when Fatigue test
yyzzjj created IMPALA-7272: -- Summary: impalad crash when Fatigue test Key: IMPALA-7272 URL: https://issues.apache.org/jira/browse/IMPALA-7272 Project: IMPALA Issue Type: Bug Components: Backend Affects Versions: Impala 2.12.0, Impala 2.11.0 Environment: apache branch [329979d6fb0caa0dc449d7e0aa75460c30e868f0] centos 6.5 Reporter: yyzzjj Attachments: e4386102-833c-40bb-4eec10b2-827c76be.dmp, impalad_node0.ERROR, impalad_node0.WARNING (gdb) bt #0 0x003269832635 in raise () from /lib64/libc.so.6 #1 0x003269833e15 in abort () from /lib64/libc.so.6 #2 0x04010f64 in google::DumpStackTraceAndExit() () #3 0x040079dd in google::LogMessage::Fail() () #4 0x04009282 in google::LogMessage::SendToLog() () #5 0x040073b7 in google::LogMessage::Flush() () #6 0x0400a97e in google::LogMessageFatal::~LogMessageFatal() () #7 0x01a2dfab in impala::MemPool::CheckIntegrity (this=0x5916e1f8, check_current_chunk_empty=true) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.cc:258 #8 0x01a2cf56 in impala::MemPool::FindChunk (this=0x5916e1f8, min_size=10, check_limits=true) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.cc:158 #9 0x01a3dd1b in impala::MemPool::Allocate (alignment=8, size=10, this=0x5916e1f8) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.h:273 #10 impala::MemPool::TryAllocate (this=0x5916e1f8, size=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.h:109 #11 0x01caefb8 in impala::StringBuffer::GrowBuffer (this=0x7f90d9489c28, new_size=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/string-buffer.h:85 #12 0x01caee18 in impala::StringBuffer::Append (this=0x7f90d9489c28, str=0x7f92cda6e039 "1104700843don...@jd.com业务运营部\230\340\246͒\177", str_len=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/string-buffer.h:53 #13 0x01cac864 in impala::StringMinMaxFilter::CopyToBuffer (this=0x7f90d9489c00, buffer=0x7f90d9489c28, value=0x7f90d9489c08, len=10) at /export/ldb/online/kudu_rpc_branch/be/src/util/min-max-filter.cc:304 #14 0x01cac2a9 in impala::StringMinMaxFilter::MaterializeValues (this=0x7f90d9489c00) at /export/ldb/online/kudu_rpc_branch/be/src/util/min-max-filter.cc:229 #15 0x02b9641a in impala::FilterContext::MaterializeValues (this=0x61cc0b70) at /export/ldb/online/kudu_rpc_branch/be/src/exec/filter-context.cc:97 #16 0x7f93fdb9440e in ?? () #17 0x7f90a97f5400 in ?? () #18 0x2acd2bba01a2e0f7 in ?? () #19 0x5916e140 in ?? () #20 0x7f930c34d740 in ?? () #21 0x7f90a97f5220 in ?? () #22 0x66aa77bb66aa77bb in ?? () #23 0x61cc0b70 in ?? () #24 0x61cc0b70 in ?? () #25 0x61cc0b98 in ?? () #26 0x61cc0b70 in ?? () #27 0x7f90a97f5300 in ?? () #28 0x01ab84ed in impala::RuntimeFilterBank::AllocateScratchMinMaxFilter (this=, filter_id=, type=) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/runtime-filter-bank.cc:250 Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7272) impalad crash when Fatigue test
yyzzjj created IMPALA-7272: -- Summary: impalad crash when Fatigue test Key: IMPALA-7272 URL: https://issues.apache.org/jira/browse/IMPALA-7272 Project: IMPALA Issue Type: Bug Components: Backend Affects Versions: Impala 2.12.0, Impala 2.11.0 Environment: apache branch [329979d6fb0caa0dc449d7e0aa75460c30e868f0] centos 6.5 Reporter: yyzzjj Attachments: e4386102-833c-40bb-4eec10b2-827c76be.dmp, impalad_node0.ERROR, impalad_node0.WARNING (gdb) bt #0 0x003269832635 in raise () from /lib64/libc.so.6 #1 0x003269833e15 in abort () from /lib64/libc.so.6 #2 0x04010f64 in google::DumpStackTraceAndExit() () #3 0x040079dd in google::LogMessage::Fail() () #4 0x04009282 in google::LogMessage::SendToLog() () #5 0x040073b7 in google::LogMessage::Flush() () #6 0x0400a97e in google::LogMessageFatal::~LogMessageFatal() () #7 0x01a2dfab in impala::MemPool::CheckIntegrity (this=0x5916e1f8, check_current_chunk_empty=true) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.cc:258 #8 0x01a2cf56 in impala::MemPool::FindChunk (this=0x5916e1f8, min_size=10, check_limits=true) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.cc:158 #9 0x01a3dd1b in impala::MemPool::Allocate (alignment=8, size=10, this=0x5916e1f8) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.h:273 #10 impala::MemPool::TryAllocate (this=0x5916e1f8, size=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/mem-pool.h:109 #11 0x01caefb8 in impala::StringBuffer::GrowBuffer (this=0x7f90d9489c28, new_size=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/string-buffer.h:85 #12 0x01caee18 in impala::StringBuffer::Append (this=0x7f90d9489c28, str=0x7f92cda6e039 "1104700843don...@jd.com业务运营部\230\340\246͒\177", str_len=10) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/string-buffer.h:53 #13 0x01cac864 in impala::StringMinMaxFilter::CopyToBuffer (this=0x7f90d9489c00, buffer=0x7f90d9489c28, value=0x7f90d9489c08, len=10) at /export/ldb/online/kudu_rpc_branch/be/src/util/min-max-filter.cc:304 #14 0x01cac2a9 in impala::StringMinMaxFilter::MaterializeValues (this=0x7f90d9489c00) at /export/ldb/online/kudu_rpc_branch/be/src/util/min-max-filter.cc:229 #15 0x02b9641a in impala::FilterContext::MaterializeValues (this=0x61cc0b70) at /export/ldb/online/kudu_rpc_branch/be/src/exec/filter-context.cc:97 #16 0x7f93fdb9440e in ?? () #17 0x7f90a97f5400 in ?? () #18 0x2acd2bba01a2e0f7 in ?? () #19 0x5916e140 in ?? () #20 0x7f930c34d740 in ?? () #21 0x7f90a97f5220 in ?? () #22 0x66aa77bb66aa77bb in ?? () #23 0x61cc0b70 in ?? () #24 0x61cc0b70 in ?? () #25 0x61cc0b98 in ?? () #26 0x61cc0b70 in ?? () #27 0x7f90a97f5300 in ?? () #28 0x01ab84ed in impala::RuntimeFilterBank::AllocateScratchMinMaxFilter (this=, filter_id=, type=) at /export/ldb/online/kudu_rpc_branch/be/src/runtime/runtime-filter-bank.cc:250 Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- 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-7271) KRPC: cross-port caching of GetLoggedInUser
Todd Lipcon created IMPALA-7271: --- Summary: KRPC: cross-port caching of GetLoggedInUser Key: IMPALA-7271 URL: https://issues.apache.org/jira/browse/IMPALA-7271 Project: IMPALA Issue Type: Bug Components: Backend Affects Versions: Impala 2.12.0 Reporter: Todd Lipcon In a production cluster I am seeing a high rate of 'mmap' calls under a workload which starts and stops a lot of exchanges. These are causing a lot contention for the mmap semaphore, which is then causing page faults to be rather slow. By running perf record -e syscalls:*mmap I can see that most of the calls are coming from KRPC's call to GetLoggedInUser when initting a Proxy object. This was fixed by https://gerrit.cloudera.org/#/c/9895/ which needs to be cherry-picked over. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (IMPALA-7186) Docs for kudu_read_mode
[ https://issues.apache.org/jira/browse/IMPALA-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7186 started by Alex Rodoni. --- > Docs for kudu_read_mode > --- > > Key: IMPALA-7186 > URL: https://issues.apache.org/jira/browse/IMPALA-7186 > Project: IMPALA > Issue Type: Task > Components: Docs >Affects Versions: Impala 3.1.0 >Reporter: Thomas Tauber-Marshall >Assignee: Alex Rodoni >Priority: Major > Labels: docs, future_release_doc > > IMPALA-6812 added a new query option, KUDU_READ_MODE, which should be > documented with something like: > KUDU_READ_MODE Query Option > This query option allows users to set a desired consistency level for scans > of Kudu tables. Possible values are DEFAULT, READ_LATEST, and > READ_AT_SNAPSHOT. If DEFAULT is specified, the value of the startup flag > '--kudu_read_mode' will be used. > READ_LATEST > Kudu provides no consistency guarantees for this mode, expect that all > returned rows were committed at some point, sometimes known as 'Read > Committed' isolation. > READ_AT_SNAPSHOT > Kudu will take a snapshot of the current state of the data and perform the > scan over the snapshot, possibly after briefly waiting for ongoing writes to > complete. This provides "Read Your Writes" consistency within a single Impala > session, except in the case of a Kudu leader change. See the Kudu > documentation for more details. > Type: string > Default: DEFAULT > Added in: Impala 3.1 -- 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-7244) Impala 3.1 Doc: Remove unsupported format write support
[ https://issues.apache.org/jira/browse/IMPALA-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni reassigned IMPALA-7244: --- Assignee: Bikramjeet Vig (was: Alex Rodoni) > Impala 3.1 Doc: Remove unsupported format write support > --- > > Key: IMPALA-7244 > URL: https://issues.apache.org/jira/browse/IMPALA-7244 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Affects Versions: Impala 3.1.0 >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Labels: future_release_doc > > the parent task removes write support for unsupported formats like > *Sequence,* *Avro and compressed text*. Also, the related query options > *ALLOW_UNSUPPORTED_FORMATS* and *SEQ_COMPRESSION_MODE* have been migrated to > the 'REMOVED' query options type and therefore are no longer functional. -- 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] [Comment Edited] (IMPALA-7269) Single quote within double-quoted string not matching
[
https://issues.apache.org/jira/browse/IMPALA-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537713#comment-16537713
]
Fredy Wijaya edited comment on IMPALA-7269 at 7/9/18 10:32 PM:
---
There has been couple bug fixes related to single/double quotes in Impala
shell. I tried to reproduce the issue on the latest Impala and was unable to
reproduce it.
{noformat}
[localhost:21000] default> create table test_table(publisher string);
Query: create table test_table(publisher string)
+-+
| summary |
+-+
| Table has been created. |
+-+
Fetched 1 row(s) in 0.03s
[localhost:21000] default> insert into test_table values("O'Reilly");
Query: insert into test_table values("O'Reilly")
Modified 1 row(s) in 3.32s
[localhost:21000] default> select * from test_table where publisher =
"O'Reilly";
Query: select * from test_table where publisher = "O'Reilly"
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
[localhost:21000] default> select * from test_table where publisher =
'O\'Reilly';
Query: select * from test_table where publisher = 'O\'Reilly'
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
{noformat}
Are you able to reproduce the issue in the latest Impala?
was (Author: fredyw):
There has been couple bug fixes related to single/double quotes in Impala
shell. I tried to reproduce on the latest Impala and was unable to reproduce
the issue.
{noformat}
[localhost:21000] default> create table test_table(publisher string);
Query: create table test_table(publisher string)
+-+
| summary |
+-+
| Table has been created. |
+-+
Fetched 1 row(s) in 0.03s
[localhost:21000] default> insert into test_table values("O'Reilly");
Query: insert into test_table values("O'Reilly")
Modified 1 row(s) in 3.32s
[localhost:21000] default> select * from test_table where publisher =
"O'Reilly";
Query: select * from test_table where publisher = "O'Reilly"
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
[localhost:21000] default> select * from test_table where publisher =
'O\'Reilly';
Query: select * from test_table where publisher = 'O\'Reilly'
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
{noformat}
Are you able to reproduce the issue in the latest Impala?
> Single quote within double-quoted string not matching
> -
>
> Key: IMPALA-7269
> URL: https://issues.apache.org/jira/browse/IMPALA-7269
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 2.10.0
>Reporter: Eric Karnowski
>Priority: Major
>
> I'm using Impala to query data with a string value:
> {{O'Reilly}}
> When I query this using double quotes to handle the single quote, it accepts
> the query but returns no rows. I have to escape the single quote with a
> backslash for it to match.
> Similarly,
> {{SELECT "O'Reilly"}}
> returns simply O
>
> I believe this is the same issue as
> https://issues.apache.org/jira/browse/IMPALA-1081 and
> https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
> "cannot reproduce".
--
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-7269) Single quote within double-quoted string not matching
[
https://issues.apache.org/jira/browse/IMPALA-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537713#comment-16537713
]
Fredy Wijaya commented on IMPALA-7269:
--
There has been couple bug fixes related to single/double quotes in Impala
shell. I tried to reproduce on the latest Impala and was unable to reproduce
the issue.
{noformat}
[localhost:21000] default> create table test_table(publisher string);
Query: create table test_table(publisher string)
+-+
| summary |
+-+
| Table has been created. |
+-+
Fetched 1 row(s) in 0.03s
[localhost:21000] default> insert into test_table values("O'Reilly");
Query: insert into test_table values("O'Reilly")
Modified 1 row(s) in 3.32s
[localhost:21000] default> select * from test_table where publisher =
"O'Reilly";
Query: select * from test_table where publisher = "O'Reilly"
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
[localhost:21000] default> select * from test_table where publisher =
'O\'Reilly';
Query: select * from test_table where publisher = 'O\'Reilly'
+---+
| publisher |
+---+
| O'Reilly |
+---+
Fetched 1 row(s) in 0.11s
{noformat}
Are you able to reproduce the issue in the latest Impala?
> Single quote within double-quoted string not matching
> -
>
> Key: IMPALA-7269
> URL: https://issues.apache.org/jira/browse/IMPALA-7269
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 2.10.0
>Reporter: Eric Karnowski
>Priority: Major
>
> I'm using Impala to query data with a string value:
> {{O'Reilly}}
> When I query this using double quotes to handle the single quote, it accepts
> the query but returns no rows. I have to escape the single quote with a
> backslash for it to match.
> Similarly,
> {{SELECT "O'Reilly"}}
> returns simply O
>
> I believe this is the same issue as
> https://issues.apache.org/jira/browse/IMPALA-1081 and
> https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
> "cannot reproduce".
--
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-7270) Improve the decimal fuzz test
Taras Bobrovytsky created IMPALA-7270: - Summary: Improve the decimal fuzz test Key: IMPALA-7270 URL: https://issues.apache.org/jira/browse/IMPALA-7270 Project: IMPALA Issue Type: Bug Components: Infrastructure Reporter: Taras Bobrovytsky The decimal fuzz test has been helpful in finding bugs in the decimal data type. However, currently it only supports arithmetic operations. Here are some ideas about how it can be expanded: * Add binary predicates (greater than, less than, etc) * Add operations with other data types for example, (decimal + bigint), (bigint <= int). * More complex expressions (d1 + d2 / d3 % d4) * Add other decimal functions, such as round(), ceil() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7270) Improve the decimal fuzz test
Taras Bobrovytsky created IMPALA-7270: - Summary: Improve the decimal fuzz test Key: IMPALA-7270 URL: https://issues.apache.org/jira/browse/IMPALA-7270 Project: IMPALA Issue Type: Bug Components: Infrastructure Reporter: Taras Bobrovytsky The decimal fuzz test has been helpful in finding bugs in the decimal data type. However, currently it only supports arithmetic operations. Here are some ideas about how it can be expanded: * Add binary predicates (greater than, less than, etc) * Add operations with other data types for example, (decimal + bigint), (bigint <= int). * More complex expressions (d1 + d2 / d3 % d4) * Add other decimal functions, such as round(), ceil() -- 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] [Comment Edited] (IMPALA-7269) Single quote within double-quoted string not matching
[
https://issues.apache.org/jira/browse/IMPALA-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537609#comment-16537609
]
Ian Cook edited comment on IMPALA-7269 at 7/9/18 9:22 PM:
--
This issue also affects expressions in the {{WHERE}} clause that compare string
columns with double-quoted literal strings. For example, when querying a table
with a {{STRING}} column named {{publisher}} with the value {{O'Reilly}} in one
or more row, the query
{{SELECT * FROM _table_ WHERE publisher = "O'Reilly";}}
returns zero rows, but the query
{{SELECT * FROM _table_ WHERE publisher = "O\'Reilly";}}
(with a backslash added before the apostrophe) will return the rows as expected.
was (Author: icook):
This issue also affects expressions in the {{WHERE}} clause that compare string
columns with double-quoted literal strings. For example, when querying a table
with a {{STRING}} column named {{publisher}} with the value {{O'Reilly}} in one
or more row, the query
{{SELECT * FROM _table_ WHERE publisher = "O'Reilly";}}
returns zero rows, but the query
{{ SELECT * FROM _table_ WHERE publisher = "O\'Reilly";}}
(with a backslash added before the apostrophe) will return the rows as expected.
> Single quote within double-quoted string not matching
> -
>
> Key: IMPALA-7269
> URL: https://issues.apache.org/jira/browse/IMPALA-7269
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 2.10.0
>Reporter: Eric Karnowski
>Priority: Major
>
> I'm using Impala to query data with a string value:
> {{O'Reilly}}
> When I query this using double quotes to handle the single quote, it accepts
> the query but returns no rows. I have to escape the single quote with a
> backslash for it to match.
> Similarly,
> {{SELECT "O'Reilly"}}
> returns simply O
>
> I believe this is the same issue as
> https://issues.apache.org/jira/browse/IMPALA-1081 and
> https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
> "cannot reproduce".
--
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-7269) Single quote within double-quoted string not matching
[
https://issues.apache.org/jira/browse/IMPALA-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537609#comment-16537609
]
Ian Cook commented on IMPALA-7269:
--
This issue also affects expressions in the {{WHERE}} clause that compare string
columns with double-quoted literal strings. For example, when querying a table
with a {{STRING}} column named {{publisher}} with the value {{O'Reilly}} in one
or more row, the query
{{SELECT * FROM _table_ WHERE publisher = "O'Reilly";}}
returns zero rows, but the query
{{ SELECT * FROM _table_ WHERE publisher = "O\'Reilly";}}
(with a backslash added before the apostrophe) will return the rows as expected.
> Single quote within double-quoted string not matching
> -
>
> Key: IMPALA-7269
> URL: https://issues.apache.org/jira/browse/IMPALA-7269
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 2.10.0
>Reporter: Eric Karnowski
>Priority: Major
>
> I'm using Impala to query data with a string value:
> {{O'Reilly}}
> When I query this using double quotes to handle the single quote, it accepts
> the query but returns no rows. I have to escape the single quote with a
> backslash for it to match.
> Similarly,
> {{SELECT "O'Reilly"}}
> returns simply O
>
> I believe this is the same issue as
> https://issues.apache.org/jira/browse/IMPALA-1081 and
> https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
> "cannot reproduce".
--
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-7269) Single quote within double-quoted string not matching
Eric Karnowski created IMPALA-7269:
--
Summary: Single quote within double-quoted string not matching
Key: IMPALA-7269
URL: https://issues.apache.org/jira/browse/IMPALA-7269
Project: IMPALA
Issue Type: Bug
Affects Versions: Impala 2.10.0
Reporter: Eric Karnowski
I'm using Impala to query data with a string value:
{{O'Reilly}}
When I query this using double quotes to handle the single quote, it accepts
the query but returns no rows. I have to escape the single quote with a
backslash for it to match.
Similarly,
{{SELECT "O'Reilly"}}
returns simply O
I believe this is the same issue as
https://issues.apache.org/jira/browse/IMPALA-1081 and
https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
"cannot reproduce".
--
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-7269) Single quote within double-quoted string not matching
Eric Karnowski created IMPALA-7269:
--
Summary: Single quote within double-quoted string not matching
Key: IMPALA-7269
URL: https://issues.apache.org/jira/browse/IMPALA-7269
Project: IMPALA
Issue Type: Bug
Affects Versions: Impala 2.10.0
Reporter: Eric Karnowski
I'm using Impala to query data with a string value:
{{O'Reilly}}
When I query this using double quotes to handle the single quote, it accepts
the query but returns no rows. I have to escape the single quote with a
backslash for it to match.
Similarly,
{{SELECT "O'Reilly"}}
returns simply O
I believe this is the same issue as
https://issues.apache.org/jira/browse/IMPALA-1081 and
https://issues.apache.org/jira/browse/IMPALA-3153 but these were closed as
"cannot reproduce".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IMPALA-4690) conv() needs substantially more documentation
[
https://issues.apache.org/jira/browse/IMPALA-4690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537562#comment-16537562
]
Alex Rodoni commented on IMPALA-4690:
-
[~jbapple] Is this something you are saving for newbies as the label indicates?
> conv() needs substantially more documentation
> -
>
> Key: IMPALA-4690
> URL: https://issues.apache.org/jira/browse/IMPALA-4690
> Project: IMPALA
> Issue Type: Bug
> Components: Docs
>Affects Versions: Impala 2.8.0
>Reporter: Jim Apple
>Assignee: Alex Rodoni
>Priority: Major
> Labels: newbie
>
> The documentation for {{conv()}} doesn't say what the limits are on the
> bases, what the output format is for digits greater than 9, or what negative
> bases do. grep for {{MathConversionFunctions}} to see some examples.
--
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-7214) Lots of misleading/incorrect use of DataNode in Impala docs
[
https://issues.apache.org/jira/browse/IMPALA-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537542#comment-16537542
]
Alex Rodoni commented on IMPALA-7214:
-
[~tarmstrong] Besides, the example you gave, how do you recommend we fix the
doc errors in a systematic way?
I ran "grep -i datanode", and a good number of doc entries were returned,
including many "datanodes running impala daemons".
> Lots of misleading/incorrect use of DataNode in Impala docs
> ---
>
> Key: IMPALA-7214
> URL: https://issues.apache.org/jira/browse/IMPALA-7214
> Project: IMPALA
> Issue Type: Bug
> Components: Docs
>Affects Versions: Impala 2.12.0
>Reporter: Tim Armstrong
>Assignee: Alex Rodoni
>Priority: Major
>
> The docs tend to conflate DataNodes (a HDFS service) and Impala daemons. I
> think this stems from the original deployment practice of always colocating
> Impala daemons with HDFS datanodes so that HDFS data could always be read
> from a local DataNode.
> I'm a bit pedantic so the conflation feels wrong to me regardless, but I
> think this will become increasingly confusing as alternative deployments
> without colocated HDFS DataNodes become more common (e.g. running against S3,
> running with a separate HDFS service).
> E.g. picking an example at random:
> {noformat}
> In Impala 1.4.0 and higher, the LIMIT clause is now
> optional (rather than required) for
> queries that use the ORDER BY clause. Impala
> automatically uses a temporary disk work area
> to perform the sort if the sort operation would otherwise exceed the
> Impala memory limit for a particular
> DataNode.
> {noformat}
> This is wrong because the memory limit is for an Impala daemon, which is the
> process that does the actual sorting. So here I think it should be "Impala
> daemon" instead of "DataNode".
--
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] [Work started] (IMPALA-7214) Lots of misleading/incorrect use of DataNode in Impala docs
[
https://issues.apache.org/jira/browse/IMPALA-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on IMPALA-7214 started by Alex Rodoni.
---
> Lots of misleading/incorrect use of DataNode in Impala docs
> ---
>
> Key: IMPALA-7214
> URL: https://issues.apache.org/jira/browse/IMPALA-7214
> Project: IMPALA
> Issue Type: Bug
> Components: Docs
>Affects Versions: Impala 2.12.0
>Reporter: Tim Armstrong
>Assignee: Alex Rodoni
>Priority: Major
>
> The docs tend to conflate DataNodes (a HDFS service) and Impala daemons. I
> think this stems from the original deployment practice of always colocating
> Impala daemons with HDFS datanodes so that HDFS data could always be read
> from a local DataNode.
> I'm a bit pedantic so the conflation feels wrong to me regardless, but I
> think this will become increasingly confusing as alternative deployments
> without colocated HDFS DataNodes become more common (e.g. running against S3,
> running with a separate HDFS service).
> E.g. picking an example at random:
> {noformat}
> In Impala 1.4.0 and higher, the LIMIT clause is now
> optional (rather than required) for
> queries that use the ORDER BY clause. Impala
> automatically uses a temporary disk work area
> to perform the sort if the sort operation would otherwise exceed the
> Impala memory limit for a particular
> DataNode.
> {noformat}
> This is wrong because the memory limit is for an Impala daemon, which is the
> process that does the actual sorting. So here I think it should be "Impala
> daemon" instead of "DataNode".
--
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-7214) Lots of misleading/incorrect use of DataNode in Impala docs
[
https://issues.apache.org/jira/browse/IMPALA-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rodoni updated IMPALA-7214:
Issue Type: Bug (was: Documentation)
> Lots of misleading/incorrect use of DataNode in Impala docs
> ---
>
> Key: IMPALA-7214
> URL: https://issues.apache.org/jira/browse/IMPALA-7214
> Project: IMPALA
> Issue Type: Bug
> Components: Docs
>Affects Versions: Impala 2.12.0
>Reporter: Tim Armstrong
>Assignee: Alex Rodoni
>Priority: Major
>
> The docs tend to conflate DataNodes (a HDFS service) and Impala daemons. I
> think this stems from the original deployment practice of always colocating
> Impala daemons with HDFS datanodes so that HDFS data could always be read
> from a local DataNode.
> I'm a bit pedantic so the conflation feels wrong to me regardless, but I
> think this will become increasingly confusing as alternative deployments
> without colocated HDFS DataNodes become more common (e.g. running against S3,
> running with a separate HDFS service).
> E.g. picking an example at random:
> {noformat}
> In Impala 1.4.0 and higher, the LIMIT clause is now
> optional (rather than required) for
> queries that use the ORDER BY clause. Impala
> automatically uses a temporary disk work area
> to perform the sort if the sort operation would otherwise exceed the
> Impala memory limit for a particular
> DataNode.
> {noformat}
> This is wrong because the memory limit is for an Impala daemon, which is the
> process that does the actual sorting. So here I think it should be "Impala
> daemon" instead of "DataNode".
--
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-6223) Gracefully handle malformed 'with' queries in impala-shell
[
https://issues.apache.org/jira/browse/IMPALA-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-6223.
--
Resolution: Fixed
> Gracefully handle malformed 'with' queries in impala-shell
> --
>
> Key: IMPALA-6223
> URL: https://issues.apache.org/jira/browse/IMPALA-6223
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
>Affects Versions: Impala 2.10.0
>Reporter: bharath v
>Assignee: Pooja Nilangekar
>Priority: Minor
> Labels: newbie
>
> Impala shell can throw a lexer error if it encounters a malformed "with"
> query.
> {noformat}
> impala-shell.sh -q "with foo as (select bar from temp where temp.a='"
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.11.0-SNAPSHOT DEBUG (build
> 0ee1765f38082bc5c10aa37b23cb8e57caa57d4e)
> Traceback (most recent call last):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1463, in
> execute_queries_non_interactive_mode(options, query_options)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1338, in
> execute_queries_non_interactive_mode
> shell.execute_query_list(queries)):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1218, in
> execute_query_list
> if self.onecmd(q) is CmdStatus.ERROR:
> File "/home/bharath/Impala/shell/impala_shell.py", line 505, in onecmd
> return cmd.Cmd.onecmd(self, line)
> File "/usr/lib/python2.7/cmd.py", line 221, in onecmd
> return func(arg)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1024, in do_with
> tokens = list(lexer)
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> This happens because we use shlex to parse the input query to determine if
> its a DML and it can throw if the input doesn't have balanced quotes.
> {noformat}
> def do_with(self, args):
> """Executes a query with a WITH clause, fetching all rows"""
> query = self.imp_client.create_beeswax_query("with %s" % args,
> self.set_query_options)
> # Set posix=True and add "'" to escaped quotes
> # to deal with escaped quotes in string literals
> lexer = shlex.shlex(query.query.lstrip(), posix=True)
> lexer.escapedquotes += "'"
> # Because the WITH clause may precede DML or SELECT queries,
> # just checking the first token is insufficient.
> is_dml = False
> tokens = list(lexer) <
> {noformat}
> A simple shlex repro of that is as follows,
> {noformat}
> >>> lexer = shlex.shlex("with foo as (select bar from temp where temp.a='",
> >>> posix=True);
> >>> list(lexer)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> Fix: Either catch the exception and handle it gracefully or have a better way
> to figure out the query type, using a SQL parser (more involved).
> This query also repros it:
> {code}
> with v as (select 1)
> select foo('\\'), ('bar
> ;
> {code}
--
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-6223) Gracefully handle malformed 'with' queries in impala-shell
[
https://issues.apache.org/jira/browse/IMPALA-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-6223.
--
Resolution: Fixed
> Gracefully handle malformed 'with' queries in impala-shell
> --
>
> Key: IMPALA-6223
> URL: https://issues.apache.org/jira/browse/IMPALA-6223
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
>Affects Versions: Impala 2.10.0
>Reporter: bharath v
>Assignee: Pooja Nilangekar
>Priority: Minor
> Labels: newbie
>
> Impala shell can throw a lexer error if it encounters a malformed "with"
> query.
> {noformat}
> impala-shell.sh -q "with foo as (select bar from temp where temp.a='"
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.11.0-SNAPSHOT DEBUG (build
> 0ee1765f38082bc5c10aa37b23cb8e57caa57d4e)
> Traceback (most recent call last):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1463, in
> execute_queries_non_interactive_mode(options, query_options)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1338, in
> execute_queries_non_interactive_mode
> shell.execute_query_list(queries)):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1218, in
> execute_query_list
> if self.onecmd(q) is CmdStatus.ERROR:
> File "/home/bharath/Impala/shell/impala_shell.py", line 505, in onecmd
> return cmd.Cmd.onecmd(self, line)
> File "/usr/lib/python2.7/cmd.py", line 221, in onecmd
> return func(arg)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1024, in do_with
> tokens = list(lexer)
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> This happens because we use shlex to parse the input query to determine if
> its a DML and it can throw if the input doesn't have balanced quotes.
> {noformat}
> def do_with(self, args):
> """Executes a query with a WITH clause, fetching all rows"""
> query = self.imp_client.create_beeswax_query("with %s" % args,
> self.set_query_options)
> # Set posix=True and add "'" to escaped quotes
> # to deal with escaped quotes in string literals
> lexer = shlex.shlex(query.query.lstrip(), posix=True)
> lexer.escapedquotes += "'"
> # Because the WITH clause may precede DML or SELECT queries,
> # just checking the first token is insufficient.
> is_dml = False
> tokens = list(lexer) <
> {noformat}
> A simple shlex repro of that is as follows,
> {noformat}
> >>> lexer = shlex.shlex("with foo as (select bar from temp where temp.a='",
> >>> posix=True);
> >>> list(lexer)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> Fix: Either catch the exception and handle it gracefully or have a better way
> to figure out the query type, using a SQL parser (more involved).
> This query also repros it:
> {code}
> with v as (select 1)
> select foo('\\'), ('bar
> ;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-6031) Distributed plan describes coordinator-only nodes as scanning
[
https://issues.apache.org/jira/browse/IMPALA-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-6031.
--
Resolution: Fixed
> Distributed plan describes coordinator-only nodes as scanning
> -
>
> Key: IMPALA-6031
> URL: https://issues.apache.org/jira/browse/IMPALA-6031
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.11.0
>Reporter: Jim Apple
>Assignee: Pooja Nilangekar
>Priority: Major
>
> In a cluster with one coordinator-only node and three executor-only nodes:
> {noformat}
> Query: explain select count(*) from web_sales a, web_sales b where
> a.ws_order_number = b.ws_order_number and a.ws_item_sk = b.ws_item_sk
> +--+
> | Explain String
> |
> +--+
> | Per-Host Resource Reservation: Memory=136.00MB
> |
> | Per-Host Resource Estimates: Memory=3.04GB
> |
> |
> |
> | F03:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> |
> | PLAN-ROOT SINK
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | |
> |
> | 07:AGGREGATE [FINALIZE]
> |
> | | output: count:merge(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 06:EXCHANGE [UNPARTITIONED]
> |
> | mem-estimate=0B mem-reservation=0B
> |
> | tuple-ids=2 row-size=8B cardinality=1
> |
> |
> |
> | F02:PLAN FRAGMENT [HASH(a.ws_item_sk,a.ws_order_number)] hosts=4
> instances=4 |
> | DATASTREAM SINK [FRAGMENT=F03, EXCHANGE=06, UNPARTITIONED]
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | 03:AGGREGATE
> |
> | | output: count(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 02:HASH JOIN [INNER JOIN, PARTITIONED]
> |
> | | hash predicates: a.ws_item_sk = b.ws_item_sk, a.ws_order_number =
> b.ws_order_number |
> | | runtime filters: RF000 <- b.ws_item_sk, RF001 <- b.ws_order_number
> |
> | | mem-estimate=2.95GB mem-reservation=136.00MB
> |
> | | tuple-ids=0,1 row-size=32B cardinality=72376
> |
> | |
> |
> | |--05:EXCHANGE [HASH(b.ws_item_sk,b.ws_order_number)]
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | | tuple-ids=1 row-size=16B cardinality=72376
> |
> | |
> |
> | 04:EXCHANGE [HASH(a.ws_item_sk,a.ws_order_number)]
> |
> | mem-estimate=0B mem-reservation=0B
> |
> | tuple-ids=0 row-size=16B cardinality=72376
> |
> |
> |
> | F00:PLAN FRAGMENT [RANDOM] hosts=4 instances=4
[jira] [Resolved] (IMPALA-6031) Distributed plan describes coordinator-only nodes as scanning
[
https://issues.apache.org/jira/browse/IMPALA-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-6031.
--
Resolution: Fixed
> Distributed plan describes coordinator-only nodes as scanning
> -
>
> Key: IMPALA-6031
> URL: https://issues.apache.org/jira/browse/IMPALA-6031
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.11.0
>Reporter: Jim Apple
>Assignee: Pooja Nilangekar
>Priority: Major
>
> In a cluster with one coordinator-only node and three executor-only nodes:
> {noformat}
> Query: explain select count(*) from web_sales a, web_sales b where
> a.ws_order_number = b.ws_order_number and a.ws_item_sk = b.ws_item_sk
> +--+
> | Explain String
> |
> +--+
> | Per-Host Resource Reservation: Memory=136.00MB
> |
> | Per-Host Resource Estimates: Memory=3.04GB
> |
> |
> |
> | F03:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> |
> | PLAN-ROOT SINK
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | |
> |
> | 07:AGGREGATE [FINALIZE]
> |
> | | output: count:merge(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 06:EXCHANGE [UNPARTITIONED]
> |
> | mem-estimate=0B mem-reservation=0B
> |
> | tuple-ids=2 row-size=8B cardinality=1
> |
> |
> |
> | F02:PLAN FRAGMENT [HASH(a.ws_item_sk,a.ws_order_number)] hosts=4
> instances=4 |
> | DATASTREAM SINK [FRAGMENT=F03, EXCHANGE=06, UNPARTITIONED]
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | 03:AGGREGATE
> |
> | | output: count(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 02:HASH JOIN [INNER JOIN, PARTITIONED]
> |
> | | hash predicates: a.ws_item_sk = b.ws_item_sk, a.ws_order_number =
> b.ws_order_number |
> | | runtime filters: RF000 <- b.ws_item_sk, RF001 <- b.ws_order_number
> |
> | | mem-estimate=2.95GB mem-reservation=136.00MB
> |
> | | tuple-ids=0,1 row-size=32B cardinality=72376
> |
> | |
> |
> | |--05:EXCHANGE [HASH(b.ws_item_sk,b.ws_order_number)]
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | | tuple-ids=1 row-size=16B cardinality=72376
> |
> | |
> |
> | 04:EXCHANGE [HASH(a.ws_item_sk,a.ws_order_number)]
> |
> | mem-estimate=0B mem-reservation=0B
> |
> | tuple-ids=0 row-size=16B cardinality=72376
> |
> |
> |
> | F00:PLAN FRAGMENT [RANDOM] hosts=4 instances=4
[jira] [Commented] (IMPALA-7075) Add support for object ownership for Impala
[ https://issues.apache.org/jira/browse/IMPALA-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537470#comment-16537470 ] ASF subversion and git services commented on IMPALA-7075: - Commit 54b3c607f027c445fc8d52acc4d3b1073e84aa77 in impala's branch refs/heads/master from [~fredyw] [ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=54b3c60 ] IMPALA-6988: Implement ALTER TABLE/VIEW SET OWNER Alter the table/view owner to either user or role. On table/view creation, the table/view owner will be set to the current user, which can be viewed via DESCRIBE FORMATTED command. Having an owner information allows implementing a feature where an owner can be given certain privileges automatically upon a table/view creation. See IMPALA-7075. The ALTER TABLE/VIEW SET OWNER will be useful commands for transferring ownership (a set of owner privileges) from the current owner to another owner. Syntax: ALTER TABLE table SET OWNER USER user ALTER TABLE table SET OWNER ROLE role ALTER VIEW view SET OWNER USER user ALTER VIEW view SET OWNER ROLE role Testing: - Added new FE tests - Added new E2E tests Change-Id: Ia1b75b1590b16eb0c2ba326d07ee3fd9897c27d1 Reviewed-on: http://gerrit.cloudera.org:8080/10822 Reviewed-by: Impala Public Jenkins Tested-by: Impala Public Jenkins > Add support for object ownership for Impala > --- > > Key: IMPALA-7075 > URL: https://issues.apache.org/jira/browse/IMPALA-7075 > Project: IMPALA > Issue Type: Epic > Components: Frontend >Reporter: Fredy Wijaya >Priority: Major > Labels: security > -- 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-6918) Implement COMMENT ON COLUMN
[
https://issues.apache.org/jira/browse/IMPALA-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537474#comment-16537474
]
ASF subversion and git services commented on IMPALA-6918:
-
Commit 2fddd39f0eb8cb4d476f35d1fe68f481444eb19b in impala's branch
refs/heads/master from [~fredyw]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=2fddd39 ]
IMPALA-6918: [DOCS] COMMENT ON COLUMN privileges
Change-Id: Ib2b3621ecc8113a165ec36beaf82cbc1d480bc54
Reviewed-on: http://gerrit.cloudera.org:8080/10890
Reviewed-by: Alex Rodoni
Tested-by: Impala Public Jenkins
> Implement COMMENT ON COLUMN
> ---
>
> Key: IMPALA-6918
> URL: https://issues.apache.org/jira/browse/IMPALA-6918
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Reporter: Fredy Wijaya
>Assignee: Fredy Wijaya
>Priority: Minor
> Fix For: Impala 3.1.0
>
>
> Syntax:
> {noformat}
> COMMENT ON COLUMN my_table.my_column IS 'Employee ID Number';{noformat}
>
>
--
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-3956) Impala shell variable substitution should ignore comments embedded in query.
[
https://issues.apache.org/jira/browse/IMPALA-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537473#comment-16537473
]
ASF subversion and git services commented on IMPALA-3956:
-
Commit a70c05ee2d295669707a2ab69d632f5b9cfab1cf in impala's branch
refs/heads/master from [~arodoni_cloudera]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=a70c05e ]
IMPALA-3956: [DOCS] Escape variables with '\' in impala-shell
Change-Id: Ifb95785a143939a94d55d3565364afe1e26c1f3d
Reviewed-on: http://gerrit.cloudera.org:8080/10861
Reviewed-by: Adam Holley
Reviewed-by: Fredy Wijaya
Tested-by: Impala Public Jenkins
> Impala shell variable substitution should ignore comments embedded in query.
>
>
> Key: IMPALA-3956
> URL: https://issues.apache.org/jira/browse/IMPALA-3956
> Project: IMPALA
> Issue Type: Bug
> Components: Clients, Docs
>Affects Versions: Impala 2.6.0
>Reporter: Huaisi Xu
>Assignee: Alex Rodoni
>Priority: Minor
> Labels: regression, usability
> Fix For: Impala 3.1.0
>
>
> {code:java}
> -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHEREa >= "${start_date}"
> {code}
> {code:java}
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.7.0-cdh5-INTERNAL DEBUG (build
> ebd65a142d3f3f4087eb1c9aaf25d53d2045a4cb)
> Error: Unknown substitution syntax (START_DATE). Use ${VAR:var_name}.
> Could not execute command: -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHERE a >= "${start_date}"
> {code}
--
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-6223) Gracefully handle malformed 'with' queries in impala-shell
[
https://issues.apache.org/jira/browse/IMPALA-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537471#comment-16537471
]
ASF subversion and git services commented on IMPALA-6223:
-
Commit 28162117ad462dfe5fd608d4c09ba02ad213285b in impala's branch
refs/heads/master from poojanilangekar
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=2816211 ]
IMPALA-6223: Gracefully handle malformed 'with' queries in impala-shell
The change handles the exception thrown by shlex while parsing a
malformed query.
This patch was tested by adding both commandline and interactive
shell tests.
Change-Id: Ibb1e9238ac67b8ad3b2caa1748a18b04f384802d
Reviewed-on: http://gerrit.cloudera.org:8080/10876
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> Gracefully handle malformed 'with' queries in impala-shell
> --
>
> Key: IMPALA-6223
> URL: https://issues.apache.org/jira/browse/IMPALA-6223
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
>Affects Versions: Impala 2.10.0
>Reporter: bharath v
>Assignee: Pooja Nilangekar
>Priority: Minor
> Labels: newbie
>
> Impala shell can throw a lexer error if it encounters a malformed "with"
> query.
> {noformat}
> impala-shell.sh -q "with foo as (select bar from temp where temp.a='"
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.11.0-SNAPSHOT DEBUG (build
> 0ee1765f38082bc5c10aa37b23cb8e57caa57d4e)
> Traceback (most recent call last):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1463, in
> execute_queries_non_interactive_mode(options, query_options)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1338, in
> execute_queries_non_interactive_mode
> shell.execute_query_list(queries)):
> File "/home/bharath/Impala/shell/impala_shell.py", line 1218, in
> execute_query_list
> if self.onecmd(q) is CmdStatus.ERROR:
> File "/home/bharath/Impala/shell/impala_shell.py", line 505, in onecmd
> return cmd.Cmd.onecmd(self, line)
> File "/usr/lib/python2.7/cmd.py", line 221, in onecmd
> return func(arg)
> File "/home/bharath/Impala/shell/impala_shell.py", line 1024, in do_with
> tokens = list(lexer)
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> This happens because we use shlex to parse the input query to determine if
> its a DML and it can throw if the input doesn't have balanced quotes.
> {noformat}
> def do_with(self, args):
> """Executes a query with a WITH clause, fetching all rows"""
> query = self.imp_client.create_beeswax_query("with %s" % args,
> self.set_query_options)
> # Set posix=True and add "'" to escaped quotes
> # to deal with escaped quotes in string literals
> lexer = shlex.shlex(query.query.lstrip(), posix=True)
> lexer.escapedquotes += "'"
> # Because the WITH clause may precede DML or SELECT queries,
> # just checking the first token is insufficient.
> is_dml = False
> tokens = list(lexer) <
> {noformat}
> A simple shlex repro of that is as follows,
> {noformat}
> >>> lexer = shlex.shlex("with foo as (select bar from temp where temp.a='",
> >>> posix=True);
> >>> list(lexer)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.7/shlex.py", line 269, in next
> token = self.get_token()
> File "/usr/lib/python2.7/shlex.py", line 96, in get_token
> raw = self.read_token()
> File "/usr/lib/python2.7/shlex.py", line 172, in read_token
> raise ValueError, "No closing quotation"
> ValueError: No closing quotation
> {noformat}
> Fix: Either catch the exception and handle it gracefully or have a better way
> to figure out the query type, using a SQL parser (more involved).
> This query also repros it:
> {code}
> with v as (select 1)
> select foo('\\'), ('bar
> ;
> {code}
--
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-6031) Distributed plan describes coordinator-only nodes as scanning
[
https://issues.apache.org/jira/browse/IMPALA-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537472#comment-16537472
]
ASF subversion and git services commented on IMPALA-6031:
-
Commit 880011fa1f2fc48f9972ad3c673a4bff838cc5ce in impala's branch
refs/heads/master from poojanilangekar
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=880011f ]
IMPALA-6031: Fix executor node count in distributed plans
Prior to this change, the planner also considered coordinator-only
nodes as executors while estimating the number of scan nodes to be
used in the distributed plan. This change ensures that only
executor nodes are considered for that estimation.
Testing:
Added a new custom cluster test to verify the same.
Change-Id: I44af6b40099a495e13a0a5dc72c491d486d23aa8
Reviewed-on: http://gerrit.cloudera.org:8080/10873
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> Distributed plan describes coordinator-only nodes as scanning
> -
>
> Key: IMPALA-6031
> URL: https://issues.apache.org/jira/browse/IMPALA-6031
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.11.0
>Reporter: Jim Apple
>Assignee: Pooja Nilangekar
>Priority: Major
>
> In a cluster with one coordinator-only node and three executor-only nodes:
> {noformat}
> Query: explain select count(*) from web_sales a, web_sales b where
> a.ws_order_number = b.ws_order_number and a.ws_item_sk = b.ws_item_sk
> +--+
> | Explain String
> |
> +--+
> | Per-Host Resource Reservation: Memory=136.00MB
> |
> | Per-Host Resource Estimates: Memory=3.04GB
> |
> |
> |
> | F03:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
> |
> | PLAN-ROOT SINK
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | |
> |
> | 07:AGGREGATE [FINALIZE]
> |
> | | output: count:merge(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 06:EXCHANGE [UNPARTITIONED]
> |
> | mem-estimate=0B mem-reservation=0B
> |
> | tuple-ids=2 row-size=8B cardinality=1
> |
> |
> |
> | F02:PLAN FRAGMENT [HASH(a.ws_item_sk,a.ws_order_number)] hosts=4
> instances=4 |
> | DATASTREAM SINK [FRAGMENT=F03, EXCHANGE=06, UNPARTITIONED]
> |
> | | mem-estimate=0B mem-reservation=0B
> |
> | 03:AGGREGATE
> |
> | | output: count(*)
> |
> | | mem-estimate=10.00MB mem-reservation=0B
> |
> | | tuple-ids=2 row-size=8B cardinality=1
> |
> | |
> |
> | 02:HASH JOIN [INNER JOIN, PARTITIONED]
> |
> | | hash predicates: a.ws_item_sk = b.ws_item_sk, a.ws_order_number =
> b.ws_order_number |
> | | runtime filters: RF000 <- b.ws_item_sk, RF001 <- b.ws_order_number
> |
> | | mem-estimate=2.95GB mem-reservation=136.00MB
> |
> | | tuple-ids=0,1 row-size=32B cardinality=72376
> |
> | |
> |
> | |--05:EXCHANGE [HASH(b.ws_item_sk,b.ws_order_number)]
[jira] [Commented] (IMPALA-7178) Reduce logging for common data errors
[ https://issues.apache.org/jira/browse/IMPALA-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537429#comment-16537429 ] Csaba Ringhofer commented on IMPALA-7178: - If the log message is the same for every line, then it could be solved by a similar solution. Currently the offset is always (?) the same, but this seems to be a bug. If the offset would be replaced with column name, then it could be aggregated in a similar way as "out-of-range parquet timestamps". > Reduce logging for common data errors > - > > Key: IMPALA-7178 > URL: https://issues.apache.org/jira/browse/IMPALA-7178 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Csaba Ringhofer >Assignee: Csaba Ringhofer >Priority: Major > > Some data errors (for example out-of-range parquet timestamps) can dominate > logs if a table contains a large number of rows with invalid data. If an > error has its own error code (see common/thrift/generate_error_codes.py), > then these errors are already aggregated to the user > (RuntimeState::LogError()) for every query, but the logs will contain a new > line for every occurrence. This is not too useful most of times, as the log > lines will repeat the same information (the corrupt data itself is not logged > as it can be sensitive information). > The best would to reduce logging without loosing information: > - the first occurrence of an error should be logged (per > query/fragment/table/file/column) to help the investigation of cases where > the data error leads to other errors and to avoid breaking log analyzer tools > that search for the current format > - other occurrences can be aggregated, like "in query Q table T column C XY > error occurred N times" > An extra goal is to avoid calling RuntimeState::LogError() for other > occurrences than the first one, as RuntimeState::LogError() uses a (per > fragment) lock. -- 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-7268) Rebase gutil on top of Kudu's latest version
Lars Volker created IMPALA-7268: --- Summary: Rebase gutil on top of Kudu's latest version Key: IMPALA-7268 URL: https://issues.apache.org/jira/browse/IMPALA-7268 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Lars Volker -- 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-7268) Rebase gutil on top of Kudu's latest version
Lars Volker created IMPALA-7268: --- Summary: Rebase gutil on top of Kudu's latest version Key: IMPALA-7268 URL: https://issues.apache.org/jira/browse/IMPALA-7268 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Lars Volker -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7267) Handle EINTR for syscalls before dumping threads
Lars Volker created IMPALA-7267: --- Summary: Handle EINTR for syscalls before dumping threads Key: IMPALA-7267 URL: https://issues.apache.org/jira/browse/IMPALA-7267 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Lars Volker Before using Kudu's support to dump threads, we need to wrap all of our syscalls in RETRY_ON_EINTR. See these changes for more context: https://gerrit.cloudera.org/#/q/RETRY_ON_EINTR+status:merged+project:kudu+branch:master -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7267) Handle EINTR for syscalls before dumping threads
Lars Volker created IMPALA-7267: --- Summary: Handle EINTR for syscalls before dumping threads Key: IMPALA-7267 URL: https://issues.apache.org/jira/browse/IMPALA-7267 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Lars Volker Before using Kudu's support to dump threads, we need to wrap all of our syscalls in RETRY_ON_EINTR. See these changes for more context: https://gerrit.cloudera.org/#/q/RETRY_ON_EINTR+status:merged+project:kudu+branch:master -- 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-6677) Impala Doc: Doc next_day function
[ https://issues.apache.org/jira/browse/IMPALA-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537399#comment-16537399 ] Alex Rodoni commented on IMPALA-6677: - https://gerrit.cloudera.org/#/c/10893/ > Impala Doc: Doc next_day function > - > > Key: IMPALA-6677 > URL: https://issues.apache.org/jira/browse/IMPALA-6677 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Affects Versions: Impala 2.11.0 >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > > +[http://gerrit.cloudera.org:8080/1943]+ -- 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-7266) test_insert failure: Unable to drop partition on s3
[
https://issues.apache.org/jira/browse/IMPALA-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bikramjeet Vig reassigned IMPALA-7266:
--
Assignee: Sailesh Mukil
> test_insert failure: Unable to drop partition on s3
> ---
>
> Key: IMPALA-7266
> URL: https://issues.apache.org/jira/browse/IMPALA-7266
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 3.1.0
>Reporter: Bikramjeet Vig
>Assignee: Sailesh Mukil
>Priority: Major
> Labels: broken-build
>
> {noformat}
> 06:01:28 === FAILURES
> ===
> 06:01:28 TestInsertQueries.test_insert[exec_option: {'sync_ddl': 0,
> '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]
> 06:01:28 query_test/test_insert.py:122: in test_insert
> 06:01:28 multiple_impalad=vector.get_value('exec_option')['sync_ddl'] ==
> 1)
> 06:01:28 .../Impala/tests/common/impala_test_suite.py:366: in run_test_case
> 06:01:28 self.execute_test_case_setup(test_section['SETUP'],
> table_format_info)
> 06:01:28 .../Impala/tests/common/impala_test_suite.py:489: in
> execute_test_case_setup
> 06:01:28 self.__drop_partitions(db_name, table_name)
> 06:01:28 .../Impala/tests/common/impala_test_suite.py:614: in
> __drop_partitions
> 06:01:28 partition, True), 'Could not drop partition: %s' % partition
> 06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2862:
> in drop_partition_by_name
> 06:01:28 return self.recv_drop_partition_by_name()
> 06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2891:
> in recv_drop_partition_by_name
> 06:01:28 raise result.o2
> 06:01:28 E MetaException: MetaException(_message='No such file or
> directory:
> s3a://impala-cdh5-s3-test/test-warehouse/functional.db/alltypesinsert/year=2009/month=4')
> {noformat}
--
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-6971) Log flooding with unhelpful parsing error message
[
https://issues.apache.org/jira/browse/IMPALA-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537391#comment-16537391
]
Csaba Ringhofer commented on IMPALA-6971:
-
IMPALA-5993 seems to deal with the same error message. There is a fix on review
( https://gerrit.cloudera.org/#/c/8747/ ), but there was no update since some
time.
> Log flooding with unhelpful parsing error message
> -
>
> Key: IMPALA-6971
> URL: https://issues.apache.org/jira/browse/IMPALA-6971
> Project: IMPALA
> Issue Type: Improvement
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Zoram Thanga
>Priority: Minor
> Labels: supportability
>
> Once in a while I've seen Impala flood the log file with messages similar to
> the following:
> {noformat}
> I0318 08:20:28.566603 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566643 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566676 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566709 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566742 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566787 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566820 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566856 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566890 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566923 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566959 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.566998 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567039 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567070 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567101 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567132 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567173 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error parsing row: file:
> hdfs://nameservice/user/hive/warehouse/mydb/mytable/part-m-0, before
> offset: 2122317824
> I0318 08:20:28.567209 984564 runtime-state.cc:168] Error from query
> cf41e4ee4f7e1273:bcc41038: Error
[jira] [Created] (IMPALA-7266) test_insert failure: Unable to drop partition on s3
Bikramjeet Vig created IMPALA-7266:
--
Summary: test_insert failure: Unable to drop partition on s3
Key: IMPALA-7266
URL: https://issues.apache.org/jira/browse/IMPALA-7266
Project: IMPALA
Issue Type: Bug
Components: Infrastructure
Affects Versions: Impala 3.1.0
Reporter: Bikramjeet Vig
{noformat}
06:01:28 === FAILURES
===
06:01:28 TestInsertQueries.test_insert[exec_option: {'sync_ddl': 0,
'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]
06:01:28 query_test/test_insert.py:122: in test_insert
06:01:28 multiple_impalad=vector.get_value('exec_option')['sync_ddl'] == 1)
06:01:28 .../Impala/tests/common/impala_test_suite.py:366: in run_test_case
06:01:28 self.execute_test_case_setup(test_section['SETUP'],
table_format_info)
06:01:28 .../Impala/tests/common/impala_test_suite.py:489: in
execute_test_case_setup
06:01:28 self.__drop_partitions(db_name, table_name)
06:01:28 .../Impala/tests/common/impala_test_suite.py:614: in __drop_partitions
06:01:28 partition, True), 'Could not drop partition: %s' % partition
06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2862: in
drop_partition_by_name
06:01:28 return self.recv_drop_partition_by_name()
06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2891: in
recv_drop_partition_by_name
06:01:28 raise result.o2
06:01:28 E MetaException: MetaException(_message='No such file or directory:
s3a://impala-cdh5-s3-test/test-warehouse/functional.db/alltypesinsert/year=2009/month=4')
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-7266) test_insert failure: Unable to drop partition on s3
Bikramjeet Vig created IMPALA-7266:
--
Summary: test_insert failure: Unable to drop partition on s3
Key: IMPALA-7266
URL: https://issues.apache.org/jira/browse/IMPALA-7266
Project: IMPALA
Issue Type: Bug
Components: Infrastructure
Affects Versions: Impala 3.1.0
Reporter: Bikramjeet Vig
{noformat}
06:01:28 === FAILURES
===
06:01:28 TestInsertQueries.test_insert[exec_option: {'sync_ddl': 0,
'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]
06:01:28 query_test/test_insert.py:122: in test_insert
06:01:28 multiple_impalad=vector.get_value('exec_option')['sync_ddl'] == 1)
06:01:28 .../Impala/tests/common/impala_test_suite.py:366: in run_test_case
06:01:28 self.execute_test_case_setup(test_section['SETUP'],
table_format_info)
06:01:28 .../Impala/tests/common/impala_test_suite.py:489: in
execute_test_case_setup
06:01:28 self.__drop_partitions(db_name, table_name)
06:01:28 .../Impala/tests/common/impala_test_suite.py:614: in __drop_partitions
06:01:28 partition, True), 'Could not drop partition: %s' % partition
06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2862: in
drop_partition_by_name
06:01:28 return self.recv_drop_partition_by_name()
06:01:28 .../Impala/shell/gen-py/hive_metastore/ThriftHiveMetastore.py:2891: in
recv_drop_partition_by_name
06:01:28 raise result.o2
06:01:28 E MetaException: MetaException(_message='No such file or directory:
s3a://impala-cdh5-s3-test/test-warehouse/functional.db/alltypesinsert/year=2009/month=4')
{noformat}
--
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] [Comment Edited] (IMPALA-3933) Backward compatibility between Hive and Impala TIMESTAMP set of timezone rules across these different libraries
[
https://issues.apache.org/jira/browse/IMPALA-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537373#comment-16537373
]
Csaba Ringhofer edited comment on IMPALA-3933 at 7/9/18 6:35 PM:
-
[~attilaj] [~zi]
I tried to reproduce this issue hoping that it is already resolved by
IMPALA-3307 - it turned out that it is now reproducible not just with
convert_legacy_hive_parquet_utc_timestamps, but also with from_utc_timestamp:
select from_utc_timestamp('1890-09-30 00:00:00', 'Europe/Budapest')
result: 1890-09-30 01:16:20
select from_utc_timestamp('1890-10-01 00:00:00', 'Europe/Budapest')
result: 1890-10-01 01:00:00
Note that the issue is not reproducible with "CET", so "CET" and
"Europe/Budapest" are actually different.
It may be related that CET was introduced in Hungary in 1890 (according to
https://en.wikipedia.org/wiki/Central_European_Time). I tried Europe/Belgrade,
where CET was introduced in 1884, and the skew starts there accordingly.
Meanwhile in Hive the result is UTC+1 even before 1890. There may be a
difference between how IANA and Hive's timezone db works, and the new timezone
db of Impala and glibc may work similarly in this regard (both are IANA based).
What makes this issue a bit worrying is that it breaks ordering:
select from_utc_timestamp('1890-09-30 22:40:00', 'Europe/Budapest')
result: 1890-09-30 23:56:20
select from_utc_timestamp('1890-09-30 22:45:00', 'Europe/Budapest');
result: 1890-09-30 23:45:00
This may lead to scenarios where Hive thinks that some data is ordered, but it
turns out to be unordered after Impala converts it to local time.
was (Author: csringhofer):
[~attilaj] [~zi]
I tried to reproduce this issue hoping that it is already resolved by
IMPALA-3307 - it turned out that it is now reproducible not just with
convert_legacy_hive_parquet_utc_timestamps, but also with from_utc_timestamp:
select from_utc_timestamp('1890-09-30 00:00:00', 'Europe/Budapest')
result: 1890-09-30 01:16:20
select from_utc_timestamp('1890-10-01 00:00:00', 'Europe/Budapest')
result: 1890-10-01 01:00:00
Note that the issue is not reproducible with "CET", so "CET" and
"Europe/Budapest" are actually different.
It may be related that CET was introduced in Hungary in 1890 (according to
https://en.wikipedia.org/wiki/Central_European_Time). I tried Europe/Belgrade,
where CET was introduced in 1884, and the skew starts there accordingly.
Meanwhile in Hive the result is UTC+1 even before 1890. There may be a
difference between how IANA and Hive's timezone db works, and the new timezone
db of Impala and glibc may works similarly in this regard (both are IANA based).
What makes this issue a bit worrying is that it breaks ordering:
select from_utc_timestamp('1890-09-30 22:40:00', 'Europe/Budapest')
result: 1890-09-30 23:56:20
select from_utc_timestamp('1890-09-30 22:45:00', 'Europe/Budapest');
result: 1890-09-30 23:45:00
This may lead to scenarios where Hive thinks that some data is ordered, but it
turns out to be unordered after Impala converts it to local time.
> Backward compatibility between Hive and Impala TIMESTAMP set of timezone
> rules across these different libraries
> ---
>
> Key: IMPALA-3933
> URL: https://issues.apache.org/jira/browse/IMPALA-3933
> Project: IMPALA
> Issue Type: New Feature
> Components: Backend
>Affects Versions: impala 2.3
>Reporter: Adriano Simone
>Priority: Minor
>
> How the TIMESTAMP skew with convert_legacy_hive_parquet_utc_timestamps=true
> Enabling --convert_legacy_hive_parquet_utc_timestamps=true seems to cause
> data skew (improper converting) upon the reading for dates earlier than 1900
> (not sure about the exact date).
> The following example was run on a server which is in CEST timezone, thus the
> time difference is GMT+1 for dates before 1900 (I'm not sure, I haven't
> checked the exact starting date of DST computation), and GMT+2 when summer
> daylight saving time was applied.
> create table itst (col1 int, myts timestamp) stored as parquet;
> From impala:
> {code:java}
> insert into itst values (1,'2016-04-15 12:34:45');
> insert into itst values (2,'1949-04-15 12:34:45');
> insert into itst values (3,'1753-04-15 12:34:45');
> insert into itst values (4,'1752-04-15 12:34:45');
> {code}
> from hive
> {code:java}
> insert into itst values (5,'2016-04-15 12:34:45');
> insert into itst values (6,'1949-04-15 12:34:45');
> insert into itst values (7,'1753-04-15 12:34:45');
> insert into itst values (8,'1752-04-15 12:34:45');
> {code}
> From impala
> {code:java}
> select * from itst order by col1;
> {code}
> Result:
> {code:java}
> Query: select * from itst
> +--+-+
> | col1 | myts|
>
[jira] [Commented] (IMPALA-3933) Backward compatibility between Hive and Impala TIMESTAMP set of timezone rules across these different libraries
[
https://issues.apache.org/jira/browse/IMPALA-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537373#comment-16537373
]
Csaba Ringhofer commented on IMPALA-3933:
-
[~attilaj] [~zi]
I tried to reproduce this issue hoping that it is already resolved by
IMPALA-3307 - it turned out that it is now reproducible not just with
convert_legacy_hive_parquet_utc_timestamps, but also with from_utc_timestamp:
select from_utc_timestamp('1890-09-30 00:00:00', 'Europe/Budapest')
result: 1890-09-30 01:16:20
select from_utc_timestamp('1890-10-01 00:00:00', 'Europe/Budapest')
result: 1890-10-01 01:00:00
Note that the issue is not reproducible with "CET", so "CET" and
"Europe/Budapest" are actually different.
It may be related that CET was introduced in Hungary in 1890 (according to
https://en.wikipedia.org/wiki/Central_European_Time). I tried Europe/Belgrade,
where CET was introduced in 1884, and the skew starts there accordingly.
Meanwhile in Hive the result is UTC+1 even before 1890. There may be a
difference between how IANA and Hive's timezone db works, and the new timezone
db of Impala and glibc may works similarly in this regard (both are IANA based).
What makes this issue a bit worrying is that it breaks ordering:
select from_utc_timestamp('1890-09-30 22:40:00', 'Europe/Budapest')
result: 1890-09-30 23:56:20
select from_utc_timestamp('1890-09-30 22:45:00', 'Europe/Budapest');
result: 1890-09-30 23:45:00
This may lead to scenarios where Hive thinks that some data is ordered, but it
turns out to be unordered after Impala converts it to local time.
> Backward compatibility between Hive and Impala TIMESTAMP set of timezone
> rules across these different libraries
> ---
>
> Key: IMPALA-3933
> URL: https://issues.apache.org/jira/browse/IMPALA-3933
> Project: IMPALA
> Issue Type: New Feature
> Components: Backend
>Affects Versions: impala 2.3
>Reporter: Adriano Simone
>Priority: Minor
>
> How the TIMESTAMP skew with convert_legacy_hive_parquet_utc_timestamps=true
> Enabling --convert_legacy_hive_parquet_utc_timestamps=true seems to cause
> data skew (improper converting) upon the reading for dates earlier than 1900
> (not sure about the exact date).
> The following example was run on a server which is in CEST timezone, thus the
> time difference is GMT+1 for dates before 1900 (I'm not sure, I haven't
> checked the exact starting date of DST computation), and GMT+2 when summer
> daylight saving time was applied.
> create table itst (col1 int, myts timestamp) stored as parquet;
> From impala:
> {code:java}
> insert into itst values (1,'2016-04-15 12:34:45');
> insert into itst values (2,'1949-04-15 12:34:45');
> insert into itst values (3,'1753-04-15 12:34:45');
> insert into itst values (4,'1752-04-15 12:34:45');
> {code}
> from hive
> {code:java}
> insert into itst values (5,'2016-04-15 12:34:45');
> insert into itst values (6,'1949-04-15 12:34:45');
> insert into itst values (7,'1753-04-15 12:34:45');
> insert into itst values (8,'1752-04-15 12:34:45');
> {code}
> From impala
> {code:java}
> select * from itst order by col1;
> {code}
> Result:
> {code:java}
> Query: select * from itst
> +--+-+
> | col1 | myts|
> +--+-+
> | 1| 2016-04-15 12:34:45 |
> | 2| 1949-04-15 12:34:45 |
> | 3| 1753-04-15 12:34:45 |
> | 4| 1752-04-15 12:34:45 |
> | 5| 2016-04-15 10:34:45 |
> | 6| 1949-04-15 10:34:45 |
> | 7| 1753-04-15 11:34:45 |
> | 8| 1752-04-15 11:34:45 |
> +--+-+
> {code}
> The timestamps are looking good, the DST differences can be seen (hive
> inserted it in local time, but impala shows it in UTC)
> From impala after setting the command line argument
> "--convert_legacy_hive_parquet_utc_timestamps=true"
> {code:java}
> select * from itst order by col1;
> {code}
> The result in this case:
> {code:java}
> Query: select * from itst order by col1
> +--+-+
> | col1 | myts|
> +--+-+
> | 1| 2016-04-15 12:34:45 |
> | 2| 1949-04-15 12:34:45 |
> | 3| 1753-04-15 12:34:45 |
> | 4| 1752-04-15 12:34:45 |
> | 5| 2016-04-15 12:34:45 |
> | 6| 1949-04-15 12:34:45 |
> | 7| 1753-04-15 12:51:05 |
> | 8| 1752-04-15 12:51:05 |
> +--+-+
> {code}
> It seems that instead of 11:34:45 it is showing 12:51:05.
--
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-6065) Document IMPALA-5743
[ https://issues.apache.org/jira/browse/IMPALA-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-6065: Issue Type: Bug (was: Documentation) > Document IMPALA-5743 > > > Key: IMPALA-6065 > URL: https://issues.apache.org/jira/browse/IMPALA-6065 > Project: IMPALA > Issue Type: Bug > Components: Docs >Affects Versions: Impala 2.10.0 >Reporter: Tim Armstrong >Assignee: Alex Rodoni >Priority: Major > > It looks like --ssl_minimum_version went into Impala 2.10 but didn't have any > accompanying docs. I believe a common use case is to disallow TLS1.0 and 1.1 > with --ssl_minimum_version=tlsv1.2 -- 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-7262) Impala Doc: Quiesce impalad without shutting down
[ https://issues.apache.org/jira/browse/IMPALA-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7262: Labels: future_release_doc (was: ) > Impala Doc: Quiesce impalad without shutting down > - > > Key: IMPALA-7262 > URL: https://issues.apache.org/jira/browse/IMPALA-7262 > 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] [Comment Edited] (IMPALA-7178) Reduce logging for common data errors
[ https://issues.apache.org/jira/browse/IMPALA-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537325#comment-16537325 ] Zoram Thanga edited comment on IMPALA-7178 at 7/9/18 5:47 PM: -- I wonder if IMPALA-6971 is an instance of this log flooding? was (Author: zoram): I wonder if IMPALA-6996 is an instance of this log flooding? > Reduce logging for common data errors > - > > Key: IMPALA-7178 > URL: https://issues.apache.org/jira/browse/IMPALA-7178 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Csaba Ringhofer >Assignee: Csaba Ringhofer >Priority: Major > > Some data errors (for example out-of-range parquet timestamps) can dominate > logs if a table contains a large number of rows with invalid data. If an > error has its own error code (see common/thrift/generate_error_codes.py), > then these errors are already aggregated to the user > (RuntimeState::LogError()) for every query, but the logs will contain a new > line for every occurrence. This is not too useful most of times, as the log > lines will repeat the same information (the corrupt data itself is not logged > as it can be sensitive information). > The best would to reduce logging without loosing information: > - the first occurrence of an error should be logged (per > query/fragment/table/file/column) to help the investigation of cases where > the data error leads to other errors and to avoid breaking log analyzer tools > that search for the current format > - other occurrences can be aggregated, like "in query Q table T column C XY > error occurred N times" > An extra goal is to avoid calling RuntimeState::LogError() for other > occurrences than the first one, as RuntimeState::LogError() uses a (per > fragment) lock. -- 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-7178) Reduce logging for common data errors
[ https://issues.apache.org/jira/browse/IMPALA-7178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537325#comment-16537325 ] Zoram Thanga commented on IMPALA-7178: -- I wonder if IMPALA-6996 is an instance of this log flooding? > Reduce logging for common data errors > - > > Key: IMPALA-7178 > URL: https://issues.apache.org/jira/browse/IMPALA-7178 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Csaba Ringhofer >Assignee: Csaba Ringhofer >Priority: Major > > Some data errors (for example out-of-range parquet timestamps) can dominate > logs if a table contains a large number of rows with invalid data. If an > error has its own error code (see common/thrift/generate_error_codes.py), > then these errors are already aggregated to the user > (RuntimeState::LogError()) for every query, but the logs will contain a new > line for every occurrence. This is not too useful most of times, as the log > lines will repeat the same information (the corrupt data itself is not logged > as it can be sensitive information). > The best would to reduce logging without loosing information: > - the first occurrence of an error should be logged (per > query/fragment/table/file/column) to help the investigation of cases where > the data error leads to other errors and to avoid breaking log analyzer tools > that search for the current format > - other occurrences can be aggregated, like "in query Q table T column C XY > error occurred N times" > An extra goal is to avoid calling RuntimeState::LogError() for other > occurrences than the first one, as RuntimeState::LogError() uses a (per > fragment) lock. -- 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-7265) Cache remote file handles
Joe McDonnell created IMPALA-7265: - Summary: Cache remote file handles Key: IMPALA-7265 URL: https://issues.apache.org/jira/browse/IMPALA-7265 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Joe McDonnell Assignee: Joe McDonnell The file handle cache currently does not allow caching remote file handles. This means that clusters that have a lot of remote reads can suffer from overloading the NameNode. Impala should be able to cache remote file handles. There are some open questions about remote file handles and whether they behave differently from local file handles. In particular: # Is there any resource constraint on the number of remote file handles open? (e.g. do they maintain a network connection?) # Are there any semantic differences in how remote file handles behave when files are deleted, overwritten, or appended? # Are there any extra failure cases for remote file handles? (i.e. if a machine goes down or a remote file handle is left open for an extended period of time) The form of caching will depend on the answers, but at the very least, it should be possible to cache a remote file handle at the level of a query so that a Parquet file with multiple columns can share file handles. -- 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-5203) from_utc_timestamp inconsistent how it handles daily savings time
[
https://issues.apache.org/jira/browse/IMPALA-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer resolved IMPALA-5203.
-
Resolution: Resolved
> from_utc_timestamp inconsistent how it handles daily savings time
> -
>
> Key: IMPALA-5203
> URL: https://issues.apache.org/jira/browse/IMPALA-5203
> Project: IMPALA
> Issue Type: Bug
> Environment: Impala Shell v2.6.0-cdh5.8.3 (9872875) built on Fri Dec
> 9 14:31:00 PST 2016
>Reporter: Lou Bershad
>Priority: Major
>
> from_utc_timestamp(ts, EDT) as the timezone adjusts the time correctly
> whether or not the timestamp being translated was during daylight savings
> time. That is, it adjusts 4 hours for dates during daylight savings time and
> 5 hours for dates during standard time. from_utc_timetamp(ts, EST) always
> adjusts by 5 hours.
> In 2017, daylight savings time started on March 12th. This query shows that
> from_utc_timestamp using EDT adjusts 5 hours on March 11th and 4 hours on
> March 13th. When using EST, it adjusts 5 hours no matter what.
> {noformat}
> [i-pvd1c1mgr-vip.vldb-bo.secureworkslab.com:21001] > select 'EST',
> from_utc_timestamp('2017-03-11', 'EST'), from_utc_timestamp('2017-03-13',
> 'EST') ;
> Query: select 'EST', from_utc_timestamp('2017-03-11', 'EST'),
> from_utc_timestamp('2017-03-13', 'EST')
> +---+-+-+
> | 'est' | from_utc_timestamp('2017-03-11', 'est') |
> from_utc_timestamp('2017-03-13', 'est') |
> +---+-+-+
> | EST | 2017-03-10 19:00:00 | 2017-03-12 19:00:00
> |
> +---+-+-+
> Fetched 1 row(s) in 0.01s
> [i-pvd1c1mgr-vip.vldb-bo.secureworkslab.com:21001] > select 'EST',
> from_utc_timestamp('2017-03-11', 'EDT'), from_utc_timestamp('2017-03-13',
> 'EDT') ;
> Query: select 'EST', from_utc_timestamp('2017-03-11', 'EDT'),
> from_utc_timestamp('2017-03-13', 'EDT')
> +---+-+-+
> | 'est' | from_utc_timestamp('2017-03-11', 'edt') |
> from_utc_timestamp('2017-03-13', 'edt') |
> +---+-+-+
> | EST | 2017-03-10 19:00:00 | 2017-03-12 20:00:00
> |
> +---+-+-+
> Fetched 1 row(s) in 0.01s
> {noformat}
> The inconsistency could be fixed either by:
> # EST acts the same as EDT and adjusts the timestamp based on whether the
> timestamp is during daylight savings time. (I feel quite strongly that this
> would be the correct choice)
> # EDT always adjusts by 4 hours
> Note: The same dichotomy exists in other US timezones: PST/PDT, CST/CDT and
> MST/MDT. The dichotomy does not exist in France (CET/CEST).
> {noformat}
> Query: select tz, from_utc_timestamp('2017-03-01', tz),
> from_utc_timestamp('2017-05-01', tz) from (
> select 'EST' tz union all
> select 'EDT' tz union all
> select 'CST' tz union all
> select 'CDT' tz union all
> select 'PST' tz union all
> select 'PDT' tz union all
> select 'CET' tz union all
> select 'CEST' tz
> ) x
> +--+--+--+
> | tz | from_utc_timestamp('2017-03-01', tz) |
> from_utc_timestamp('2017-05-01', tz) |
> +--+--+--+
> | EST | 2017-02-28 19:00:00 | 2017-04-30 19:00:00
>|
> | EDT | 2017-02-28 19:00:00 | 2017-04-30 20:00:00
>|
> | CST | 2017-02-28 18:00:00 | 2017-04-30 19:00:00
>|
> | CDT | 2017-02-28 18:00:00 | 2017-04-30 19:00:00
>|
> | PST | 2017-02-28 16:00:00 | 2017-04-30 17:00:00
>|
> | PDT | 2017-02-28 16:00:00 | 2017-04-30 17:00:00
>|
> | CET | 2017-03-01 01:00:00 | 2017-05-01 02:00:00
>|
> | CEST | 2017-03-01 01:00:00 | 2017-05-01 02:00:00
>|
> +--+--+--+
> Fetched 8 row(s) in 0.02s
> {noformat}
>
--
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:
[jira] [Commented] (IMPALA-5203) from_utc_timestamp inconsistent how it handles daily savings time
[
https://issues.apache.org/jira/browse/IMPALA-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537261#comment-16537261
]
Csaba Ringhofer commented on IMPALA-5203:
-
IMPALA-3307 replaced the timezone implementation and removed several
non-canonical timezone names - this includes EDT/CDT/PDT/CEST. It is possible
to add aliases in the new implementation, so these names could be re-added by
setting them as aliases for EST/CST/PAST/CET.
> from_utc_timestamp inconsistent how it handles daily savings time
> -
>
> Key: IMPALA-5203
> URL: https://issues.apache.org/jira/browse/IMPALA-5203
> Project: IMPALA
> Issue Type: Bug
> Environment: Impala Shell v2.6.0-cdh5.8.3 (9872875) built on Fri Dec
> 9 14:31:00 PST 2016
>Reporter: Lou Bershad
>Priority: Major
>
> from_utc_timestamp(ts, EDT) as the timezone adjusts the time correctly
> whether or not the timestamp being translated was during daylight savings
> time. That is, it adjusts 4 hours for dates during daylight savings time and
> 5 hours for dates during standard time. from_utc_timetamp(ts, EST) always
> adjusts by 5 hours.
> In 2017, daylight savings time started on March 12th. This query shows that
> from_utc_timestamp using EDT adjusts 5 hours on March 11th and 4 hours on
> March 13th. When using EST, it adjusts 5 hours no matter what.
> {noformat}
> [i-pvd1c1mgr-vip.vldb-bo.secureworkslab.com:21001] > select 'EST',
> from_utc_timestamp('2017-03-11', 'EST'), from_utc_timestamp('2017-03-13',
> 'EST') ;
> Query: select 'EST', from_utc_timestamp('2017-03-11', 'EST'),
> from_utc_timestamp('2017-03-13', 'EST')
> +---+-+-+
> | 'est' | from_utc_timestamp('2017-03-11', 'est') |
> from_utc_timestamp('2017-03-13', 'est') |
> +---+-+-+
> | EST | 2017-03-10 19:00:00 | 2017-03-12 19:00:00
> |
> +---+-+-+
> Fetched 1 row(s) in 0.01s
> [i-pvd1c1mgr-vip.vldb-bo.secureworkslab.com:21001] > select 'EST',
> from_utc_timestamp('2017-03-11', 'EDT'), from_utc_timestamp('2017-03-13',
> 'EDT') ;
> Query: select 'EST', from_utc_timestamp('2017-03-11', 'EDT'),
> from_utc_timestamp('2017-03-13', 'EDT')
> +---+-+-+
> | 'est' | from_utc_timestamp('2017-03-11', 'edt') |
> from_utc_timestamp('2017-03-13', 'edt') |
> +---+-+-+
> | EST | 2017-03-10 19:00:00 | 2017-03-12 20:00:00
> |
> +---+-+-+
> Fetched 1 row(s) in 0.01s
> {noformat}
> The inconsistency could be fixed either by:
> # EST acts the same as EDT and adjusts the timestamp based on whether the
> timestamp is during daylight savings time. (I feel quite strongly that this
> would be the correct choice)
> # EDT always adjusts by 4 hours
> Note: The same dichotomy exists in other US timezones: PST/PDT, CST/CDT and
> MST/MDT. The dichotomy does not exist in France (CET/CEST).
> {noformat}
> Query: select tz, from_utc_timestamp('2017-03-01', tz),
> from_utc_timestamp('2017-05-01', tz) from (
> select 'EST' tz union all
> select 'EDT' tz union all
> select 'CST' tz union all
> select 'CDT' tz union all
> select 'PST' tz union all
> select 'PDT' tz union all
> select 'CET' tz union all
> select 'CEST' tz
> ) x
> +--+--+--+
> | tz | from_utc_timestamp('2017-03-01', tz) |
> from_utc_timestamp('2017-05-01', tz) |
> +--+--+--+
> | EST | 2017-02-28 19:00:00 | 2017-04-30 19:00:00
>|
> | EDT | 2017-02-28 19:00:00 | 2017-04-30 20:00:00
>|
> | CST | 2017-02-28 18:00:00 | 2017-04-30 19:00:00
>|
> | CDT | 2017-02-28 18:00:00 | 2017-04-30 19:00:00
>|
> | PST | 2017-02-28 16:00:00 | 2017-04-30 17:00:00
>|
> | PDT | 2017-02-28 16:00:00 | 2017-04-30 17:00:00
>|
> | CET | 2017-03-01 01:00:00 | 2017-05-01 02:00:00
>|
> | CEST | 2017-03-01 01:00:00 | 2017-05-01 02:00:00
>|
>
[jira] [Resolved] (IMPALA-1577) Improve from_utc_timestamp perf which is unpredictable and slow
[ https://issues.apache.org/jira/browse/IMPALA-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer resolved IMPALA-1577. - Resolution: Resolved > Improve from_utc_timestamp perf which is unpredictable and slow > --- > > Key: IMPALA-1577 > URL: https://issues.apache.org/jira/browse/IMPALA-1577 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.0 >Reporter: Skye Wanderman-Milne >Priority: Minor > Labels: performance > > The performance of from_utc_timestamp, besides being extremely poor compared > to that of other builtin functions such as from_unixtime, depends greatly on > the input timezone. Given that evaluating this function can dominate the > total query time, it would be good to at least make its performance more > consistent, and even better to improve its performance overall. -- 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-1577) Improve from_utc_timestamp perf which is unpredictable and slow
[ https://issues.apache.org/jira/browse/IMPALA-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer resolved IMPALA-1577. - Resolution: Resolved > Improve from_utc_timestamp perf which is unpredictable and slow > --- > > Key: IMPALA-1577 > URL: https://issues.apache.org/jira/browse/IMPALA-1577 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.0 >Reporter: Skye Wanderman-Milne >Priority: Minor > Labels: performance > > The performance of from_utc_timestamp, besides being extremely poor compared > to that of other builtin functions such as from_unixtime, depends greatly on > the input timezone. Given that evaluating this function can dominate the > total query time, it would be good to at least make its performance more > consistent, and even better to improve its performance overall. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IMPALA-1577) Improve from_utc_timestamp perf which is unpredictable and slow
[ https://issues.apache.org/jira/browse/IMPALA-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537222#comment-16537222 ] Csaba Ringhofer commented on IMPALA-1577: - IMPALA-3307 replaced the timezone implementation, which became generally faster and should be more consistent. The old implementation looked up timezone aliases much slower than canonical timezone names, while there shouldn't be any difference in the new one (many aliases were removed, while some were added to a map for fast lookups). > Improve from_utc_timestamp perf which is unpredictable and slow > --- > > Key: IMPALA-1577 > URL: https://issues.apache.org/jira/browse/IMPALA-1577 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.0 >Reporter: Skye Wanderman-Milne >Priority: Minor > Labels: performance > > The performance of from_utc_timestamp, besides being extremely poor compared > to that of other builtin functions such as from_unixtime, depends greatly on > the input timezone. Given that evaluating this function can dominate the > total query time, it would be good to at least make its performance more > consistent, and even better to improve its performance overall. -- 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-7241) progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
[
https://issues.apache.org/jira/browse/IMPALA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16537206#comment-16537206
]
Michael Brown commented on IMPALA-7241:
---
I've done several other stress runs and not seen this again. For now, that
means I'll not label this a broken build.
> progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
> ---
>
> Key: IMPALA-7241
> URL: https://issues.apache.org/jira/browse/IMPALA-7241
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Michael Brown
>Priority: Blocker
> Labels: crash, stress
>
> During a stress test with 8 nodes running an insecure debug build based off
> master, an impalad hit a DCHECK. The concurrency level at the time was
> between 150-180 queries.
> The DCHECK was {{progress-updater.cc:43] Check failed: delta >= 0 (-3 vs.
> 0)}}.
> The stack was:
> {noformat}
> #0 0x7f6a73e811f7 in raise () from /lib64/libc.so.6
> #1 0x7f6a73e828e8 in abort () from /lib64/libc.so.6
> #2 0x04300e34 in google::DumpStackTraceAndExit() ()
> #3 0x042f78ad in google::LogMessage::Fail() ()
> #4 0x042f9152 in google::LogMessage::SendToLog() ()
> #5 0x042f7287 in google::LogMessage::Flush() ()
> #6 0x042fa84e in google::LogMessageFatal::~LogMessageFatal() ()
> #7 0x01f7fedd in impala::ProgressUpdater::Update(long) ()
> #8 0x0313912b in
> impala::Coordinator::BackendState::InstanceStats::Update(impala::TFragmentInstanceExecStatus
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #9 0x031369e6 in
> impala::Coordinator::BackendState::ApplyExecStatusReport(impala::TReportExecStatusParams
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #10 0x031250b4 in
> impala::Coordinator::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #11 0x01e86395 in
> impala::ClientRequestState::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #12 0x01e27594 in
> impala::ImpalaServer::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #13 0x01ebb8a0 in
> impala::ImpalaInternalService::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #14 0x02fa6f62 in
> impala::ImpalaInternalServiceProcessor::process_ReportExecStatus(int,
> apache::thrift::protocol::TProtocol*, apache::thrift::protocol::TProtocol*,
> void*) ()
> #15 0x02fa6540 in
> impala::ImpalaInternalServiceProcessor::dispatchCall(apache::thrift::protocol::TProtocol*,
> apache::thrift::protocol::TProtocol*, std::string const&, int, void*) ()
> #16 0x018892b0 in
> apache::thrift::TDispatchProcessor::process(boost::shared_ptr,
> boost::shared_ptr, void*) ()
> #17 0x01c80d1b in
> apache::thrift::server::TAcceptQueueServer::Task::run() ()
> #18 0x01c78ffb in
> impala::ThriftThread::RunRunnable(boost::shared_ptr,
> impala::Promise*) ()
> #19 0x01c7a721 in boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise (impala::PromiseMode)0>*>::operator()(impala::ThriftThread*,
> boost::shared_ptr,
> impala::Promise*) const ()
> #20 0x01c7a5b7 in void
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*>
> >::operator() boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf2 impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>&,
> boost::_bi::list0&, int) ()
> #21 0x01c7a303 in boost::_bi::bind_t impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >::operator()() ()
> #22 0x01c7a216 in
> boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >, void>::invoke(boost::detail::function::function_buffer&) ()
> #23 0x01bbb81c in boost::function0::operator()() const ()
> #24 0x01fb6eaf in impala::Thread::SuperviseThread(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*) ()
> #25 0x01fbef87 in void
> boost::_bi::list5,
> boost::_bi::value, boost::_bi::value >,
> boost::_bi::value,
> boost::_bi::value*>
> >::operator() boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*),
> boost::_bi::list0>(boost::_bi::type, void (*&)(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*), boost::_bi::list0&, int) ()
> #26 0x01fbeeab in
[jira] [Closed] (IMPALA-3956) Impala shell variable substitution should ignore comments embedded in query.
[
https://issues.apache.org/jira/browse/IMPALA-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rodoni closed IMPALA-3956.
---
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Impala shell variable substitution should ignore comments embedded in query.
>
>
> Key: IMPALA-3956
> URL: https://issues.apache.org/jira/browse/IMPALA-3956
> Project: IMPALA
> Issue Type: Bug
> Components: Clients, Docs
>Affects Versions: Impala 2.6.0
>Reporter: Huaisi Xu
>Assignee: Alex Rodoni
>Priority: Minor
> Labels: regression, usability
> Fix For: Impala 3.1.0
>
>
> {code:java}
> -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHEREa >= "${start_date}"
> {code}
> {code:java}
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.7.0-cdh5-INTERNAL DEBUG (build
> ebd65a142d3f3f4087eb1c9aaf25d53d2045a4cb)
> Error: Unknown substitution syntax (START_DATE). Use ${VAR:var_name}.
> Could not execute command: -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHERE a >= "${start_date}"
> {code}
--
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-3956) Impala shell variable substitution should ignore comments embedded in query.
[
https://issues.apache.org/jira/browse/IMPALA-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rodoni closed IMPALA-3956.
---
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Impala shell variable substitution should ignore comments embedded in query.
>
>
> Key: IMPALA-3956
> URL: https://issues.apache.org/jira/browse/IMPALA-3956
> Project: IMPALA
> Issue Type: Bug
> Components: Clients, Docs
>Affects Versions: Impala 2.6.0
>Reporter: Huaisi Xu
>Assignee: Alex Rodoni
>Priority: Minor
> Labels: regression, usability
> Fix For: Impala 3.1.0
>
>
> {code:java}
> -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHEREa >= "${start_date}"
> {code}
> {code:java}
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 2.7.0-cdh5-INTERNAL DEBUG (build
> ebd65a142d3f3f4087eb1c9aaf25d53d2045a4cb)
> Error: Unknown substitution syntax (START_DATE). Use ${VAR:var_name}.
> Could not execute command: -- WHERE a >= "${start_date}"
> select
> *
> from --fda;
> test
> -- WHERE a >= "${start_date}"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-6988) Statement to allow setting ownership for table/view
[
https://issues.apache.org/jira/browse/IMPALA-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fredy Wijaya resolved IMPALA-6988.
--
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Statement to allow setting ownership for table/view
> ---
>
> Key: IMPALA-6988
> URL: https://issues.apache.org/jira/browse/IMPALA-6988
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Affects Versions: Impala 3.0, Impala 2.13.0
>Reporter: Adam Holley
>Assignee: Fredy Wijaya
>Priority: Major
> Labels: security
> Fix For: Impala 3.1.0
>
>
> Create statement to allow setting owner.
> {noformat}
> ALTER TABLE database_name.table_name SET OWNER [USER|ROLE] user_or_role;
> ALTER VIEW database_name.view_name SET OWNER [USER|ROLE]
> user_or_role;{noformat}
> Examples:
> {noformat}
> ALTER TABLE SET OWNER USER
> ALTER TABLE SET OWNER ROLE
> ALTER VIEW SET OWNER USER
> ALTER VIEW SET OWNER ROLE
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-6988) Statement to allow setting ownership for table/view
[
https://issues.apache.org/jira/browse/IMPALA-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fredy Wijaya resolved IMPALA-6988.
--
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Statement to allow setting ownership for table/view
> ---
>
> Key: IMPALA-6988
> URL: https://issues.apache.org/jira/browse/IMPALA-6988
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Affects Versions: Impala 3.0, Impala 2.13.0
>Reporter: Adam Holley
>Assignee: Fredy Wijaya
>Priority: Major
> Labels: security
> Fix For: Impala 3.1.0
>
>
> Create statement to allow setting owner.
> {noformat}
> ALTER TABLE database_name.table_name SET OWNER [USER|ROLE] user_or_role;
> ALTER VIEW database_name.view_name SET OWNER [USER|ROLE]
> user_or_role;{noformat}
> Examples:
> {noformat}
> ALTER TABLE SET OWNER USER
> ALTER TABLE SET OWNER ROLE
> ALTER VIEW SET OWNER USER
> ALTER VIEW SET OWNER ROLE
> {noformat}
>
--
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] [Work started] (IMPALA-1624) Allow toggling --quiet and -B settings interactively in impala-shell
[ https://issues.apache.org/jira/browse/IMPALA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-1624 started by Nghia Le. > Allow toggling --quiet and -B settings interactively in impala-shell > > > Key: IMPALA-1624 > URL: https://issues.apache.org/jira/browse/IMPALA-1624 > Project: IMPALA > Issue Type: Improvement > Components: Clients >Affects Versions: Impala 2.1 >Reporter: John Russell >Assignee: Nghia Le >Priority: Minor > Labels: ramp-up, shell, usability > > I find it is quite common to start impala-shell with the --quiet option, then > within the same session want to turn on the extra output like the timing > numbers. Or to start with the normal ASCII boxes for query output, then want > to switch to comma-delimited output. Currently, this involves quitting out of > the shell and restarting it, plus doing an extra USE or -d to get back to the > same database as before. > I suggest having some command in the shell to switch between quiet and > verbose mode, boxed and delimited output, and set the delimiter character. > Perhaps there are other similar command-line settings that would be easy to > toggle while the interpreter is running. -- 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-1624) Allow toggling --quiet and -B settings interactively in impala-shell
[ https://issues.apache.org/jira/browse/IMPALA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer reassigned IMPALA-1624: --- Assignee: Nghia Le > Allow toggling --quiet and -B settings interactively in impala-shell > > > Key: IMPALA-1624 > URL: https://issues.apache.org/jira/browse/IMPALA-1624 > Project: IMPALA > Issue Type: Improvement > Components: Clients >Affects Versions: Impala 2.1 >Reporter: John Russell >Assignee: Nghia Le >Priority: Minor > Labels: ramp-up, shell, usability > > I find it is quite common to start impala-shell with the --quiet option, then > within the same session want to turn on the extra output like the timing > numbers. Or to start with the normal ASCII boxes for query output, then want > to switch to comma-delimited output. Currently, this involves quitting out of > the shell and restarting it, plus doing an extra USE or -d to get back to the > same database as before. > I suggest having some command in the shell to switch between quiet and > verbose mode, boxed and delimited output, and set the delimiter character. > Perhaps there are other similar command-line settings that would be easy to > toggle while the interpreter is running. -- 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-7264) Set owner type upon table creation
[ https://issues.apache.org/jira/browse/IMPALA-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredy Wijaya updated IMPALA-7264: - Labels: security (was: ) > Set owner type upon table creation > -- > > Key: IMPALA-7264 > URL: https://issues.apache.org/jira/browse/IMPALA-7264 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 3.0 >Reporter: Fredy Wijaya >Assignee: Fredy Wijaya >Priority: Major > Labels: security > > Currently only owner name is set upon table creation. We need to also set > owner type upon table creation. -- 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] [Work started] (IMPALA-7264) Set owner type upon table creation
[ https://issues.apache.org/jira/browse/IMPALA-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7264 started by Fredy Wijaya. > Set owner type upon table creation > -- > > Key: IMPALA-7264 > URL: https://issues.apache.org/jira/browse/IMPALA-7264 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 3.0 >Reporter: Fredy Wijaya >Assignee: Fredy Wijaya >Priority: Major > Labels: security > > Currently only owner name is set upon table creation. We need to also set > owner type upon table creation. -- 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-7264) Set owner type upon table creation
Fredy Wijaya created IMPALA-7264: Summary: Set owner type upon table creation Key: IMPALA-7264 URL: https://issues.apache.org/jira/browse/IMPALA-7264 Project: IMPALA Issue Type: Sub-task Components: Frontend Affects Versions: Impala 3.0 Reporter: Fredy Wijaya Assignee: Fredy Wijaya Currently only owner name is set upon table creation. We need to also set owner type upon table creation. -- 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-7264) Set owner type upon table creation
Fredy Wijaya created IMPALA-7264: Summary: Set owner type upon table creation Key: IMPALA-7264 URL: https://issues.apache.org/jira/browse/IMPALA-7264 Project: IMPALA Issue Type: Sub-task Components: Frontend Affects Versions: Impala 3.0 Reporter: Fredy Wijaya Assignee: Fredy Wijaya Currently only owner name is set upon table creation. We need to also set owner type upon table creation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7263) Impala Doc: Cancel Shutdown of impalad
Alex Rodoni created IMPALA-7263: --- Summary: Impala Doc: Cancel Shutdown of impalad Key: IMPALA-7263 URL: https://issues.apache.org/jira/browse/IMPALA-7263 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni -- 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-7263) Impala Doc: Cancel Shutdown of impalad
Alex Rodoni created IMPALA-7263: --- Summary: Impala Doc: Cancel Shutdown of impalad Key: IMPALA-7263 URL: https://issues.apache.org/jira/browse/IMPALA-7263 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7262) Impala Doc: Quiesce impalad without shutting down
Alex Rodoni created IMPALA-7262: --- Summary: Impala Doc: Quiesce impalad without shutting down Key: IMPALA-7262 URL: https://issues.apache.org/jira/browse/IMPALA-7262 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7262) Impala Doc: Quiesce impalad without shutting down
Alex Rodoni created IMPALA-7262: --- Summary: Impala Doc: Quiesce impalad without shutting down Key: IMPALA-7262 URL: https://issues.apache.org/jira/browse/IMPALA-7262 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni -- 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-1624) Allow toggling --quiet and -B settings interactively in impala-shell
[ https://issues.apache.org/jira/browse/IMPALA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536877#comment-16536877 ] Csaba Ringhofer commented on IMPALA-1624: - I would add --output_file as a good candidate to set interactively. I often run into situations when I want to write the results of some queries into file, while read others in the shell. > Allow toggling --quiet and -B settings interactively in impala-shell > > > Key: IMPALA-1624 > URL: https://issues.apache.org/jira/browse/IMPALA-1624 > Project: IMPALA > Issue Type: Improvement > Components: Clients >Affects Versions: Impala 2.1 >Reporter: John Russell >Priority: Minor > Labels: ramp-up, shell, usability > > I find it is quite common to start impala-shell with the --quiet option, then > within the same session want to turn on the extra output like the timing > numbers. Or to start with the normal ASCII boxes for query output, then want > to switch to comma-delimited output. Currently, this involves quitting out of > the shell and restarting it, plus doing an extra USE or -d to get back to the > same database as before. > I suggest having some command in the shell to switch between quiet and > verbose mode, boxed and delimited output, and set the delimiter character. > Perhaps there are other similar command-line settings that would be easy to > toggle while the interpreter is running. -- 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-5542) Impala cannot scan Parquet decimal stored as int64_t/int32_t
[ https://issues.apache.org/jira/browse/IMPALA-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltán Borók-Nagy reassigned IMPALA-5542: - Assignee: Zoltán Borók-Nagy > Impala cannot scan Parquet decimal stored as int64_t/int32_t > > > Key: IMPALA-5542 > URL: https://issues.apache.org/jira/browse/IMPALA-5542 > Project: IMPALA > Issue Type: Sub-task > Components: Backend >Affects Versions: Impala 2.10.0 >Reporter: Tim Armstrong >Assignee: Zoltán Borók-Nagy >Priority: Major > Labels: parquet > > This is supported according to the Parquet spec > (https://github.com/Parquet/parquet-format/blob/master/LogicalTypes.md#decimal) > but wasn't widely used. For some reason Spark decided to start writing this > out as the default (see SPARK-20297) so we will likely start seeing this at > some point. -- 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
