[jira] [Updated] (HAWQ-991) Add support for "HAWQ register" that could register tables by using "hawq extract" output
[ https://issues.apache.org/jira/browse/HAWQ-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongwu updated HAWQ-991: Affects Version/s: 2.0.1.0-incubating > Add support for "HAWQ register" that could register tables by using "hawq > extract" output > - > > Key: HAWQ-991 > URL: https://issues.apache.org/jira/browse/HAWQ-991 > Project: Apache HAWQ > Issue Type: Improvement > Components: Command Line Tools, External Tables >Affects Versions: 2.0.1.0-incubating >Reporter: hongwu >Assignee: hongwu > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HAWQ-991) Add support for "HAWQ register" that could register tables by using "hawq extract" output
[ https://issues.apache.org/jira/browse/HAWQ-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongwu reassigned HAWQ-991: --- Assignee: hongwu (was: Lei Chang) > Add support for "HAWQ register" that could register tables by using "hawq > extract" output > - > > Key: HAWQ-991 > URL: https://issues.apache.org/jira/browse/HAWQ-991 > Project: Apache HAWQ > Issue Type: Improvement > Components: Command Line Tools, External Tables >Reporter: hongwu >Assignee: hongwu > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-991) Add support for "HAWQ register" that could register tables by using "hawq extract" output
hongwu created HAWQ-991: --- Summary: Add support for "HAWQ register" that could register tables by using "hawq extract" output Key: HAWQ-991 URL: https://issues.apache.org/jira/browse/HAWQ-991 Project: Apache HAWQ Issue Type: Improvement Components: Command Line Tools, External Tables Reporter: hongwu Assignee: Lei Chang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] incubator-hawq issue #842: HAWQ-939. Add coverity scan badge
Github user huor commented on the issue: https://github.com/apache/incubator-hawq/pull/842 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq pull request #842: HAWQ-939. Add coverity scan badge
GitHub user xunzhang opened a pull request: https://github.com/apache/incubator-hawq/pull/842 HAWQ-939. Add coverity scan badge You can merge this pull request into a Git repository by running: $ git pull https://github.com/xunzhang/incubator-hawq HAWQ-939 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-hawq/pull/842.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #842 commit 92f71288f8b1f93144045b64eb64e8beab45c777 Author: xunzhang Date: 2016-08-09T05:51:23Z HAWQ-939. Add coverity scan badge --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #842: HAWQ-939. Add coverity scan badge
Github user xunzhang commented on the issue: https://github.com/apache/incubator-hawq/pull/842 cc @liming01 @huor --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (HAWQ-990) Union clause break with distributed by clause
[ https://issues.apache.org/jira/browse/HAWQ-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongwu resolved HAWQ-990. - Resolution: Fixed Fix Version/s: 2.0.1.0-incubating > Union clause break with distributed by clause > - > > Key: HAWQ-990 > URL: https://issues.apache.org/jira/browse/HAWQ-990 > Project: Apache HAWQ > Issue Type: Bug > Components: Parser, Planner >Affects Versions: 2.0.1.0-incubating >Reporter: hongwu >Assignee: hongwu > Fix For: 2.0.1.0-incubating > > > It causes core dump when using UNION clause together with DISTRIBUTED BY > clause. > For example: > create table t3 as (select * from t1 union select * from t2) distributed > randomly; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HAWQ-990) Union clause break with distributed by clause
[ https://issues.apache.org/jira/browse/HAWQ-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongwu reassigned HAWQ-990: --- Assignee: hongwu (was: Lei Chang) > Union clause break with distributed by clause > - > > Key: HAWQ-990 > URL: https://issues.apache.org/jira/browse/HAWQ-990 > Project: Apache HAWQ > Issue Type: Bug > Components: Parser, Planner >Affects Versions: 2.0.1.0-incubating >Reporter: hongwu >Assignee: hongwu > > It causes core dump when using UNION clause together with DISTRIBUTED BY > clause. > For example: > create table t3 as (select * from t1 union select * from t2) distributed > randomly; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-990) Union clause break with distributed by clause
[ https://issues.apache.org/jira/browse/HAWQ-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hongwu updated HAWQ-990: Affects Version/s: 2.0.1.0-incubating > Union clause break with distributed by clause > - > > Key: HAWQ-990 > URL: https://issues.apache.org/jira/browse/HAWQ-990 > Project: Apache HAWQ > Issue Type: Bug > Components: Parser, Planner >Affects Versions: 2.0.1.0-incubating >Reporter: hongwu >Assignee: Lei Chang > > It causes core dump when using UNION clause together with DISTRIBUTED BY > clause. > For example: > create table t3 as (select * from t1 union select * from t2) distributed > randomly; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] incubator-hawq pull request #:
Github user xunzhang commented on the pull request: https://github.com/apache/incubator-hawq/commit/2097cee2179dafb93b06881501263fb076dd700f#commitcomment-18569112 https://github.com/apache/incubator-hawq/pull/818 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #818: HAWQ-955. Add scriptS for feature test running in...
Github user xunzhang commented on the issue: https://github.com/apache/incubator-hawq/pull/818 Merged into master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq pull request #818: HAWQ-955. Add scriptS for feature test run...
Github user xunzhang closed the pull request at: https://github.com/apache/incubator-hawq/pull/818 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq pull request #:
Github user xunzhang commented on the pull request: https://github.com/apache/incubator-hawq/commit/4bbd4a15d28bdf4900620d7eab784089011747df#commitcomment-18569102 https://github.com/apache/incubator-hawq/pull/841 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #841: HAWQ-990. Union clause break with distributed by ...
Github user xunzhang commented on the issue: https://github.com/apache/incubator-hawq/pull/841 Merged into master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq pull request #841: HAWQ-990. Union clause break with distribu...
Github user xunzhang closed the pull request at: https://github.com/apache/incubator-hawq/pull/841 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #841: HAWQ-990. Union clause break with distributed by ...
Github user radarwave commented on the issue: https://github.com/apache/incubator-hawq/pull/841 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #841: HAWQ-990. Union clause break with distributed by ...
Github user huor commented on the issue: https://github.com/apache/incubator-hawq/pull/841 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #841: HAWQ-990. Union clause break with distributed by ...
Github user xunzhang commented on the issue: https://github.com/apache/incubator-hawq/pull/841 cc @huor @radarwave --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq pull request #841: HAWQ-990. Union clause break with distribu...
GitHub user xunzhang opened a pull request: https://github.com/apache/incubator-hawq/pull/841 HAWQ-990. Union clause break with distributed by clause. You can merge this pull request into a Git repository by running: $ git pull https://github.com/xunzhang/incubator-hawq HAWQ-990 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-hawq/pull/841.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #841 commit ce622cee784b4dee421f87c14431728995d1b335 Author: xunzhang Date: 2016-08-09T04:28:45Z HAWQ-990. Union clause break with distributed by clause. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (HAWQ-990) Union clause break with distributed by clause
hongwu created HAWQ-990: --- Summary: Union clause break with distributed by clause Key: HAWQ-990 URL: https://issues.apache.org/jira/browse/HAWQ-990 Project: Apache HAWQ Issue Type: Bug Components: Parser, Planner Reporter: hongwu Assignee: Lei Chang It causes core dump when using UNION clause together with DISTRIBUTED BY clause. For example: create table t3 as (select * from t1 union select * from t2) distributed randomly; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HAWQ-834) Refactor goh_portals checkinstall cases using new test framework.
[ https://issues.apache.org/jira/browse/HAWQ-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Jin reassigned HAWQ-834: --- Assignee: Yi Jin (was: Ivan Weng) > Refactor goh_portals checkinstall cases using new test framework. > - > > Key: HAWQ-834 > URL: https://issues.apache.org/jira/browse/HAWQ-834 > Project: Apache HAWQ > Issue Type: Sub-task > Components: Tests >Reporter: Hubert Zhang >Assignee: Yi Jin > Fix For: 2.0.1.0-incubating > > > refactor goh_portals with new test framework -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] incubator-hawq issue #835: HAWQ-980. hawq does not handle guc value with spa...
Github user wengyanqing commented on the issue: https://github.com/apache/incubator-hawq/pull/835 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (HAWQ-961) Dispatch session user info, instead of current BOOTSTRAP_SUPERUSERID, from master to segments
[ https://issues.apache.org/jira/browse/HAWQ-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Guo closed HAWQ-961. - Resolution: Fixed > Dispatch session user info, instead of current BOOTSTRAP_SUPERUSERID, from > master to segments > - > > Key: HAWQ-961 > URL: https://issues.apache.org/jira/browse/HAWQ-961 > Project: Apache HAWQ > Issue Type: Bug >Reporter: Paul Guo >Assignee: Paul Guo > Fix For: 2.0.1.0-incubating > > > This does not affect the functionality and security of hawq, but there are > users who want the session user id info on segments to do something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-989) PL/Python function with psycopg2 cannot connect to hawq itself
Ruilong Huo created HAWQ-989:
Summary: PL/Python function with psycopg2 cannot connect to hawq
itself
Key: HAWQ-989
URL: https://issues.apache.org/jira/browse/HAWQ-989
Project: Apache HAWQ
Issue Type: Bug
Components: Core
Reporter: Ruilong Huo
Assignee: Lei Chang
For one use case I want to connect to hawq itself from hawq PL/Python function
using python psycopg2 library to retrieve some information. However, it errors
with "authentication failed for user "gpadmin": invalid authentication method"
{noformat}
DROP FUNCTION IF EXISTS connection_test();
DROP FUNCTION
CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
$$
import psycopg2
try:
conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
port=5433")
return "Connection successful "
except Exception , msg :
return "Exception: {m}".format(m=msg)
$$
LANGUAGE 'plpythonu' VOLATILE;
CREATE FUNCTION
SELECT * FROM connection_test();
connection_test
Exception: FATAL: authentication failed for user "gpadmin": invalid
authentication method
(1 row)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-989) PL/Python function with psycopg2 cannot connect to hawq itself
[
https://issues.apache.org/jira/browse/HAWQ-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruilong Huo updated HAWQ-989:
-
Fix Version/s: backlog
> PL/Python function with psycopg2 cannot connect to hawq itself
> --
>
> Key: HAWQ-989
> URL: https://issues.apache.org/jira/browse/HAWQ-989
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Ruilong Huo
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to hawq itself from hawq PL/Python
> function using python psycopg2 library to retrieve some information. However,
> it errors with "authentication failed for user "gpadmin": invalid
> authentication method"
> {noformat}
> DROP FUNCTION IF EXISTS connection_test();
> DROP FUNCTION
> CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
> $$
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
> port=5432")
> return "Connection successful "
> except Exception , msg :
> return "Exception: {m}".format(m=msg)
> $$
> LANGUAGE 'plpythonu' VOLATILE;
> CREATE FUNCTION
> SELECT * FROM connection_test();
> connection_test
>
> Exception: FATAL: authentication failed for user "gpadmin": invalid
> authentication method
> (1 row)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HAWQ-989) PL/Python function with psycopg2 cannot connect to hawq itself
[
https://issues.apache.org/jira/browse/HAWQ-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruilong Huo reassigned HAWQ-989:
Assignee: Ruilong Huo (was: Lei Chang)
> PL/Python function with psycopg2 cannot connect to hawq itself
> --
>
> Key: HAWQ-989
> URL: https://issues.apache.org/jira/browse/HAWQ-989
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Ruilong Huo
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to hawq itself from hawq PL/Python
> function using python psycopg2 library to retrieve some information. However,
> it errors with "authentication failed for user "gpadmin": invalid
> authentication method"
> {noformat}
> DROP FUNCTION IF EXISTS connection_test();
> DROP FUNCTION
> CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
> $$
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
> port=5432")
> return "Connection successful "
> except Exception , msg :
> return "Exception: {m}".format(m=msg)
> $$
> LANGUAGE 'plpythonu' VOLATILE;
> CREATE FUNCTION
> SELECT * FROM connection_test();
> connection_test
>
> Exception: FATAL: authentication failed for user "gpadmin": invalid
> authentication method
> (1 row)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-989) PL/Python function with psycopg2 cannot connect to hawq itself
[
https://issues.apache.org/jira/browse/HAWQ-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruilong Huo updated HAWQ-989:
-
Description:
For one use case I want to connect to hawq itself from hawq PL/Python function
using python psycopg2 library to retrieve some information. However, it errors
with "authentication failed for user "gpadmin": invalid authentication method"
{noformat}
DROP FUNCTION IF EXISTS connection_test();
DROP FUNCTION
CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
$$
import psycopg2
try:
conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
port=5432")
return "Connection successful "
except Exception , msg :
return "Exception: {m}".format(m=msg)
$$
LANGUAGE 'plpythonu' VOLATILE;
CREATE FUNCTION
SELECT * FROM connection_test();
connection_test
Exception: FATAL: authentication failed for user "gpadmin": invalid
authentication method
(1 row)
{noformat}
was:
For one use case I want to connect to hawq itself from hawq PL/Python function
using python psycopg2 library to retrieve some information. However, it errors
with "authentication failed for user "gpadmin": invalid authentication method"
{noformat}
DROP FUNCTION IF EXISTS connection_test();
DROP FUNCTION
CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
$$
import psycopg2
try:
conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
port=5433")
return "Connection successful "
except Exception , msg :
return "Exception: {m}".format(m=msg)
$$
LANGUAGE 'plpythonu' VOLATILE;
CREATE FUNCTION
SELECT * FROM connection_test();
connection_test
Exception: FATAL: authentication failed for user "gpadmin": invalid
authentication method
(1 row)
{noformat}
> PL/Python function with psycopg2 cannot connect to hawq itself
> --
>
> Key: HAWQ-989
> URL: https://issues.apache.org/jira/browse/HAWQ-989
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Ruilong Huo
>Assignee: Lei Chang
>
> For one use case I want to connect to hawq itself from hawq PL/Python
> function using python psycopg2 library to retrieve some information. However,
> it errors with "authentication failed for user "gpadmin": invalid
> authentication method"
> {noformat}
> DROP FUNCTION IF EXISTS connection_test();
> DROP FUNCTION
> CREATE OR REPLACE FUNCTION connection_test( ) RETURNS text AS
> $$
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='gptest' user='gpadmin' host='localhost'
> port=5432")
> return "Connection successful "
> except Exception , msg :
> return "Exception: {m}".format(m=msg)
> $$
> LANGUAGE 'plpythonu' VOLATILE;
> CREATE FUNCTION
> SELECT * FROM connection_test();
> connection_test
>
> Exception: FATAL: authentication failed for user "gpadmin": invalid
> authentication method
> (1 row)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-982) PL/Python function with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruilong Huo updated HAWQ-982:
-
Summary: PL/Python function with psycopg2 cannot connect to remote postgres
(was: PL/Python with psycopg2 cannot connect to remote postgres)
> PL/Python function with psycopg2 cannot connect to remote postgres
> --
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code below:
> CREATE OR REPLACE FUNCTION dchoma.connection_test( ) RETURNS text AS
> $$
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='database_name' user='user'
> host='remote_host' password='pass' port=5432")
> return "Connection successful "
> except Exception , msg :
> return "Exception: {m}".format(m=msg)
> $$
> LANGUAGE 'plpythonu' VOLATILE;
> select * from dchoma.connection_test();
> HAWQ version 2.0.1.0 build dev ( compiled from github)
> Remote database version: PostgreSQL 9.2.15 on x86_64-redhat-linux-gnu,
> compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4), 64-bit
> OS: CentOS 7-1511
> i found similar issiue here, but the problem is not solved.
> https://discuss.zendesk.com/hc/en-us/community/posts/200793368-greenplum-dblink-postgresql-remote-is-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] incubator-hawq issue #839: HAWQ-983. Fix bug that minirepro generates wrong ...
Github user changleicn commented on the issue: https://github.com/apache/incubator-hawq/pull/839 LGTM --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Comment Edited] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo edited comment on HAWQ-982 at 8/9/16 2:06 AM:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
1. Background: in hawq and postgres, we support libpq v1.0 ~ v3.0. The packet
of any connection request would start with packet length and then libpq
version. The version is represented in an unsigned int32, say v. The version is
composed of two parts: major version and minor version, which are extracted as
below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
2. Analysis: we currently use libpq v3.0 in hawq and postgres by default. When
we connect to remote postgres from udf in hawq, the client psycopg2 uses hawq's
libpq and sends version with 1879244800 (0111 0011 in
binary) in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq
reserves higher 4 bits of the version and uses them specially. Here it adds
0111 to the higher 4 bits before it sends the request packet. Thus,
1) For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
2) For the version sent from libpq in postgres, the major version is extracted
as 3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
was (Author: huor):
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
1. Background: In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet
of any connection request would start with packet length and then libpq
version. The version is represented in an unsigned int32, say v. The version is
composed of two parts: major version and minor version, which are extracted as
below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
2. Analysis: we currently use libpq v3.0 in hawq and postgres by default. When
we connect to remote postgres from udf in hawq, the client psycopg2 uses hawq's
libpq and sends version with 1879244800 (0111 0011 in
binary) in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq
reserves higher 4 bits of the version and uses them specially. Here it adds
0111 to the higher 4 bits before it sends the request packet. Thus,
1) For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
2) For the version sent from libpq in postgres, the major version is extracted
as 3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> m
[jira] [Comment Edited] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo edited comment on HAWQ-982 at 8/9/16 2:04 AM:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
Background: In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of
any connection request would start with packet length and then libpq version.
The version is represented in an unsigned int32, say v. The version is composed
of two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
Analysis: we currently use libpq v3.0 in hawq and postgres by default. When we
connect to remote postgres from udf in hawq, the client psycopg2 uses hawq's
libpq and sends version with 1879244800 (0111 0011 in
binary) in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq
reserves higher 4 bits of the version and uses them specially. Here it adds
0111 to the higher 4 bits before it sends the request packet. Thus,
1) For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
2) For the version sent from libpq in postgres, the major version is extracted
as 3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
was (Author: huor):
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in an unsigned int32, say v. The version is composed of
two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here it adds 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code below:
> CREATE OR REPLACE FUNCTION dchom
[jira] [Comment Edited] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo edited comment on HAWQ-982 at 8/9/16 2:04 AM:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
1. Background: In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet
of any connection request would start with packet length and then libpq
version. The version is represented in an unsigned int32, say v. The version is
composed of two parts: major version and minor version, which are extracted as
below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
2. Analysis: we currently use libpq v3.0 in hawq and postgres by default. When
we connect to remote postgres from udf in hawq, the client psycopg2 uses hawq's
libpq and sends version with 1879244800 (0111 0011 in
binary) in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq
reserves higher 4 bits of the version and uses them specially. Here it adds
0111 to the higher 4 bits before it sends the request packet. Thus,
1) For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
2) For the version sent from libpq in postgres, the major version is extracted
as 3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
was (Author: huor):
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
Background: In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of
any connection request would start with packet length and then libpq version.
The version is represented in an unsigned int32, say v. The version is composed
of two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
Analysis: we currently use libpq v3.0 in hawq and postgres by default. When we
connect to remote postgres from udf in hawq, the client psycopg2 uses hawq's
libpq and sends version with 1879244800 (0111 0011 in
binary) in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq
reserves higher 4 bits of the version and uses them specially. Here it adds
0111 to the higher 4 bits before it sends the request packet. Thus,
1) For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
2) For the version sent from libpq in postgres, the major version is extracted
as 3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code
[jira] [Comment Edited] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo edited comment on HAWQ-982 at 8/9/16 2:02 AM:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in an unsigned int32, say v. The version is composed of
two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here it adds 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
was (Author: huor):
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in an unsigned int32, say v. The version is composed of
two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here is add 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code below:
> CREATE OR REPLACE FUNCTION dchoma.connection_test( ) RETURNS text AS
[jira] [Comment Edited] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo edited comment on HAWQ-982 at 8/9/16 2:00 AM:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in an unsigned int32, say v. The version is composed of
two parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here is add 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
was (Author: huor):
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in a unsigned int32 v. The version is composed of two
parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here is add 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code below:
> CREATE OR REPLACE FUNCTION dchoma.connection_test( ) RETURNS text AS
> $$
>
[jira] [Commented] (HAWQ-982) PL/Python with psycopg2 cannot connect to remote postgres
[
https://issues.apache.org/jira/browse/HAWQ-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412822#comment-15412822
]
Ruilong Huo commented on HAWQ-982:
--
RCA: the root cause is compatibility issue between libpq protocol in hawq and
postgres since we modified libpq versioning mechanism in hawq.
To be specific, here are details:
In hawq and postgres, we support libpq v1.0 ~ v3.0. The packet of any
connection request would start with packet length and then libpq version. The
version is represented in a unsigned int32 v. The version is composed of two
parts: major version and minor version, which are extracted as below:
{noformat}
### hawq
/* Upper four bits used special by hawq */
#define PG_PROTOCOL_MAJOR(v)(((v) >> 16) & 0xfff)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
### postgres
#define PG_PROTOCOL_MAJOR(v)((v) >> 16)
#define PG_PROTOCOL_MINOR(v)((v) & 0x)
{noformat}
We currently use libpq v3.0 in hawq and postgres by default. When we connect to
remote postgres from udf in hawq, the client psycopg2 uses hawq's libpq and
sends version with 1879244800 (0111 0011 in binary)
in packet. Where it sends version with 196608 ( 0011
in binary) if psycopg2 uses postgres's libpq. Note that hawq reserves
higher 4 bits of the version and uses them specially. Here is add 0111 to the
higher 4 bits before it sends the request packet.
For the version sent from libpq in hawq, the major version is extracted as
28675 (0111 0011 in binary), and the minor version is extracted as 0
( in binary). The reflects the error message "unsupported
frontend protocol 28675.0: server supports 1.0 to 3.0".
For the version sent from libpq in postgres, the major version is extracted as
3 ( 0011 in binary), and the minor version is extracted as 0
( in binary). Thus the query works as the version 3.0 is
between supported version 1.0 ~ 3.0.
> PL/Python with psycopg2 cannot connect to remote postgres
> -
>
> Key: HAWQ-982
> URL: https://issues.apache.org/jira/browse/HAWQ-982
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Core
>Reporter: Lei Chang
>Assignee: Ruilong Huo
> Fix For: backlog
>
>
> For one use case I want to connect to external postgreSQL database from HAWQ
> PL/Python procedure.
> I use python psycopg2 library.
> Remote postgreSQL server reject connecion from HAWQ with
> this error : FATAL unsupported frontend protocol 28675.0: server supports
> 1.0 to 3.0.
> The same python code is running well from OS level.
> I wonder if it is HAWQ or PostgreSQL PL/Python interpreter related issiue.
> Any help or pointers would be great.
> ---
> my code below:
> CREATE OR REPLACE FUNCTION dchoma.connection_test( ) RETURNS text AS
> $$
> import psycopg2
> try:
> conn = psycopg2.connect("dbname='database_name' user='user'
> host='remote_host' password='pass' port=5432")
> return "Connection successful "
> except Exception , msg :
> return "Exception: {m}".format(m=msg)
> $$
> LANGUAGE 'plpythonu' VOLATILE;
> select * from dchoma.connection_test();
> HAWQ version 2.0.1.0 build dev ( compiled from github)
> Remote database version: PostgreSQL 9.2.15 on x86_64-redhat-linux-gnu,
> compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4), 64-bit
> OS: CentOS 7-1511
> i found similar issiue here, but the problem is not solved.
> https://discuss.zendesk.com/hc/en-us/community/posts/200793368-greenplum-dblink-postgresql-remote-is-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] incubator-hawq issue #825: HAWQ-961. Dispatch session user id (not current B...
Github user paul-guo- commented on the issue: https://github.com/apache/incubator-hawq/pull/825 Merged. Closing. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #840: HAWQ-985. Add feature test for agg with groupings...
Github user linwen commented on the issue: https://github.com/apache/incubator-hawq/pull/840 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #825: HAWQ-961. Dispatch session user id (not current B...
Github user zhangh43 commented on the issue: https://github.com/apache/incubator-hawq/pull/825 +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] incubator-hawq issue #840: HAWQ-985. Add feature test for agg with groupings...
Github user jiny2 commented on the issue: https://github.com/apache/incubator-hawq/pull/840 LGTM +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (HAWQ-988) Add feature test for create agg
zhenglin tao created HAWQ-988: - Summary: Add feature test for create agg Key: HAWQ-988 URL: https://issues.apache.org/jira/browse/HAWQ-988 Project: Apache HAWQ Issue Type: Sub-task Components: Tests Reporter: zhenglin tao Assignee: Jiali Yao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HAWQ-988) Add feature test for create agg using new test framework
[ https://issues.apache.org/jira/browse/HAWQ-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhenglin tao reassigned HAWQ-988: - Assignee: zhenglin tao (was: Jiali Yao) > Add feature test for create agg using new test framework > > > Key: HAWQ-988 > URL: https://issues.apache.org/jira/browse/HAWQ-988 > Project: Apache HAWQ > Issue Type: Sub-task > Components: Tests >Reporter: zhenglin tao >Assignee: zhenglin tao > Fix For: 2.0.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-988) Add feature test for create agg using new test framework
[ https://issues.apache.org/jira/browse/HAWQ-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhenglin tao updated HAWQ-988: -- Summary: Add feature test for create agg using new test framework (was: Add feature test for create agg) > Add feature test for create agg using new test framework > > > Key: HAWQ-988 > URL: https://issues.apache.org/jira/browse/HAWQ-988 > Project: Apache HAWQ > Issue Type: Sub-task > Components: Tests >Reporter: zhenglin tao >Assignee: Jiali Yao > Fix For: 2.0.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HAWQ-987) Add feature test for agg with derived win using new test framework
[ https://issues.apache.org/jira/browse/HAWQ-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhenglin tao reassigned HAWQ-987: - Assignee: zhenglin tao (was: Jiali Yao) > Add feature test for agg with derived win using new test framework > -- > > Key: HAWQ-987 > URL: https://issues.apache.org/jira/browse/HAWQ-987 > Project: Apache HAWQ > Issue Type: Sub-task > Components: Tests >Reporter: zhenglin tao >Assignee: zhenglin tao > Fix For: 2.0.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-987) Add feature test for agg with derived win using new test framework
zhenglin tao created HAWQ-987: - Summary: Add feature test for agg with derived win using new test framework Key: HAWQ-987 URL: https://issues.apache.org/jira/browse/HAWQ-987 Project: Apache HAWQ Issue Type: Sub-task Components: Tests Reporter: zhenglin tao Assignee: Jiali Yao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] incubator-hawq pull request #840: HAWQ-985. Add feature test for agg with gr...
GitHub user ztao1987 opened a pull request: https://github.com/apache/incubator-hawq/pull/840 HAWQ-985. Add feature test for agg with groupingsets and null. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ztao1987/incubator-hawq HAWQ-985 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-hawq/pull/840.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #840 commit a27b92b907b3d252d1b29aeba22db1e4f03bc2c2 Author: ztao1987 Date: 2016-08-08T22:25:13Z HAWQ-985. Add feature test for agg with groupingsets and null. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (HAWQ-986) Redundant Fragmenter API Call from Reading External Table
[ https://issues.apache.org/jira/browse/HAWQ-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goden Yao updated HAWQ-986: --- Summary: Redundant Fragmenter API Call from Reading External Table (was: Do not call fragmenter api twice) > Redundant Fragmenter API Call from Reading External Table > - > > Key: HAWQ-986 > URL: https://issues.apache.org/jira/browse/HAWQ-986 > Project: Apache HAWQ > Issue Type: Bug > Components: PXF >Reporter: Oleksandr Diachenko >Assignee: Goden Yao > Fix For: backlog > > > Right now, when HAWQ does select from external PXF table it does two > fragmenter calls, seems like it's redundant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HAWQ-986) Redundant Fragmenter API Call from Reading External Table
[ https://issues.apache.org/jira/browse/HAWQ-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412473#comment-15412473 ] Goden Yao commented on HAWQ-986: Can you also post code snippet and point the exact redundant location? Update in the description > Redundant Fragmenter API Call from Reading External Table > - > > Key: HAWQ-986 > URL: https://issues.apache.org/jira/browse/HAWQ-986 > Project: Apache HAWQ > Issue Type: Bug > Components: PXF >Reporter: Oleksandr Diachenko >Assignee: Goden Yao > Fix For: backlog > > > Right now, when HAWQ does select from external PXF table it does two > fragmenter calls, seems like it's redundant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-986) Do not call fragmenter api twice
[ https://issues.apache.org/jira/browse/HAWQ-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goden Yao updated HAWQ-986: --- Fix Version/s: backlog > Do not call fragmenter api twice > > > Key: HAWQ-986 > URL: https://issues.apache.org/jira/browse/HAWQ-986 > Project: Apache HAWQ > Issue Type: Bug > Components: PXF >Reporter: Oleksandr Diachenko >Assignee: Goden Yao > Fix For: backlog > > > Right now, when HAWQ does select from external PXF table it does two > fragmenter calls, seems like it's redundant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-986) Do not call fragmenter api twice
[ https://issues.apache.org/jira/browse/HAWQ-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleksandr Diachenko updated HAWQ-986: - Description: Right now, when HAWQ does select from external PXF table it does two fragmenter calls, seems like it's redundant. > Do not call fragmenter api twice > > > Key: HAWQ-986 > URL: https://issues.apache.org/jira/browse/HAWQ-986 > Project: Apache HAWQ > Issue Type: Bug > Components: PXF >Reporter: Oleksandr Diachenko >Assignee: Goden Yao > > Right now, when HAWQ does select from external PXF table it does two > fragmenter calls, seems like it's redundant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-986) Do not call fragmenter api twice
Oleksandr Diachenko created HAWQ-986: Summary: Do not call fragmenter api twice Key: HAWQ-986 URL: https://issues.apache.org/jira/browse/HAWQ-986 Project: Apache HAWQ Issue Type: Bug Components: PXF Reporter: Oleksandr Diachenko Assignee: Goden Yao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-983) Minirepro generate wrong dependency order of objects and miss CTE relations
[ https://issues.apache.org/jira/browse/HAWQ-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Goden Yao updated HAWQ-983: --- Fix Version/s: (was: 2.0.0.0-incubating) 2.0.1.0-incubating > Minirepro generate wrong dependency order of objects and miss CTE relations > --- > > Key: HAWQ-983 > URL: https://issues.apache.org/jira/browse/HAWQ-983 > Project: Apache HAWQ > Issue Type: Bug > Components: Command Line Tools >Reporter: Haisheng Yuan >Assignee: Haisheng Yuan > Fix For: 2.0.1.0-incubating > > > The minirepro generate scripts in the wrong dependency order if dtabase > relations are in different schemas. In addition, it misses relations in CTE > and function objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goden Yao updated HAWQ-981:
---
Fix Version/s: backlog
> create PXF External tables in HAWQ,Query error
> ---
>
> Key: HAWQ-981
> URL: https://issues.apache.org/jira/browse/HAWQ-981
> Project: Apache HAWQ
> Issue Type: Bug
> Components: PXF
>Affects Versions: 2.0.0.0-incubating
>Reporter: litiebiao
>Assignee: Lei Chang
> Fix For: backlog
>
>
> create EXTERNAL table DR_S1APP2P_TDR_20160720(
> PROTOCOLID SMALLINT,
> GLOBALIDNUMERIC(22),
> SESSIONID NUMERIC(22),
> CDRID NUMERIC(22),
> XDRTYPE SMALLINT,
> IMSIVARCHAR(16),
> IMEIVARCHAR(26),
> MSISDN VARCHAR(26),
> EVENTID SMALLINT,
> BTIME timestamp,
> ETIME timestamp,
> EVENTRESULT SMALLINT,
> EVENTCAUSE SMALLINT,
> REQUESTCAUSE SMALLINT,
> EVENTTYPE SMALLINT,
> EVENTTYPE1 SMALLINT,
> MMEADDRESS VARCHAR(40),
> ENBADDRESS VARCHAR(40),
> MMEPORT SMALLINT,
> ENBPORT SMALLINT,
> MMES1APUEID INT,
> ENBS1APUEID INT,
> MMEGRPID SMALLINT,
> MMECODE SMALLINT,
> MTMSI VARCHAR(8),
> OLDGUTITYPE SMALLINT,
> OLDMMEGRPIDSMALLINT,
> OLDMMECODE SMALLINT,
> OLDMTMSIVARCHAR(8),
> TMSIVARCHAR(8),
> UEIPV4ADDR VARCHAR(40),
> UEIPV6ADDR VARCHAR(40),
> ETAC SMALLINT,
> PEERTAC SMALLINT,
> ECI INT,
> PEERECI INT,
> LACSMALLINT,
> OLDLAC SMALLINT,
> CSFBRESULT SMALLINT,
> NASPROCFLAG SMALLINT,
> S1APPROCFLAGSMALLINT,
> ERABFLAGSMALLINT,
> PAGINGTYPE SMALLINT,
> VOICEDOMAIN SMALLINT,
> PAGINGDOMAINSMALLINT,
> UECENTRIC SMALLINT,
> VOPSOPT SMALLINT,
> EMMCAUSE SMALLINT,
> ESMCAUSE SMALLINT,
> CTXTSTPCAUSE SMALLINT,
> CTXTMODCAUSE SMALLINT,
> S1RELCAUSE SMALLINT,
> AUTHREQOFFSET SMALLINT,
> AUTHRESOFFSET SMALLINT,
> SECUCMDOFFSET SMALLINT,
> SECUCPLOFFSET SMALLINT,
> CTXTSTPREQOFFSET SMALLINT,
> CTXTSTPRSPOFFSET SMALLINT,
> PAGINGRSPOFFSET SMALLINT,
> CTXTMODREQOFFSETINT,
> CTXTMODRSPOFFSETINT,
> S1RELOFFSET INT,
> INITREQERABNUM SMALLINT,
> INITSUCERABNUM SMALLINT,
> STPREQERABNUM SMALLINT,
> STPSUCERABNUM SMALLINT,
> MODREQERABNUM SMALLINT,
> MODSUCERABNUM SMALLINT,
> CTXTSTPSTATUS SMALLINT,
> CTXTMODSTATUS SMALLINT,
> AUTHSTATUS SMALLINT,
> SECUSTATUS SMALLINT,
> CAUSE1 SMALLINT,
> CAUSE2 SMALLINT,
> OFFSET1 INT,
> OFFSET2 INT,
> CALLINGNUM VARCHAR(26),
> CALLEDNUM VARCHAR(26),
> SMCNUMBER VARCHAR(26),
> ATAC SMALLINT,
> AECIINT,
> UCUESRVCCSUPPORTSMALLINT,
> EVENTCAUSETYPE SMALLINT,
> REQEVENTCAUSETYPE SMALLINT,
> ENBID SMALLINT,
> ENBMID SMALLINT,
> MMEID SMALLINT,
> MMEMID SMALLINT,
> AREAID SMALLINT,
> TAC VARCHAR(8),
> UETYPEID SMALLINT,
> TYPEID SMALLINT,
> MANUFACTURERID SMALLINT,
> RECVTIMEtimestamp,
> REGIONID SMALLINT,
> XDRNUMBER SMALLINT,
> SESSIONQCI SMALLINT
> ) LOCATION
> ('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
> FORMAT 'TEXT' (DELIMITER = E'\t');
> select * from DR_S1APP2P_TDR_20160720 limit 10;
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> ** 错误 **
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> SQL 状态: XX000
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goden Yao updated HAWQ-981:
---
Affects Version/s: 2.0.0.0-incubating
> create PXF External tables in HAWQ,Query error
> ---
>
> Key: HAWQ-981
> URL: https://issues.apache.org/jira/browse/HAWQ-981
> Project: Apache HAWQ
> Issue Type: Bug
> Components: PXF
>Affects Versions: 2.0.0.0-incubating
>Reporter: litiebiao
>Assignee: Lei Chang
> Fix For: backlog
>
>
> create EXTERNAL table DR_S1APP2P_TDR_20160720(
> PROTOCOLID SMALLINT,
> GLOBALIDNUMERIC(22),
> SESSIONID NUMERIC(22),
> CDRID NUMERIC(22),
> XDRTYPE SMALLINT,
> IMSIVARCHAR(16),
> IMEIVARCHAR(26),
> MSISDN VARCHAR(26),
> EVENTID SMALLINT,
> BTIME timestamp,
> ETIME timestamp,
> EVENTRESULT SMALLINT,
> EVENTCAUSE SMALLINT,
> REQUESTCAUSE SMALLINT,
> EVENTTYPE SMALLINT,
> EVENTTYPE1 SMALLINT,
> MMEADDRESS VARCHAR(40),
> ENBADDRESS VARCHAR(40),
> MMEPORT SMALLINT,
> ENBPORT SMALLINT,
> MMES1APUEID INT,
> ENBS1APUEID INT,
> MMEGRPID SMALLINT,
> MMECODE SMALLINT,
> MTMSI VARCHAR(8),
> OLDGUTITYPE SMALLINT,
> OLDMMEGRPIDSMALLINT,
> OLDMMECODE SMALLINT,
> OLDMTMSIVARCHAR(8),
> TMSIVARCHAR(8),
> UEIPV4ADDR VARCHAR(40),
> UEIPV6ADDR VARCHAR(40),
> ETAC SMALLINT,
> PEERTAC SMALLINT,
> ECI INT,
> PEERECI INT,
> LACSMALLINT,
> OLDLAC SMALLINT,
> CSFBRESULT SMALLINT,
> NASPROCFLAG SMALLINT,
> S1APPROCFLAGSMALLINT,
> ERABFLAGSMALLINT,
> PAGINGTYPE SMALLINT,
> VOICEDOMAIN SMALLINT,
> PAGINGDOMAINSMALLINT,
> UECENTRIC SMALLINT,
> VOPSOPT SMALLINT,
> EMMCAUSE SMALLINT,
> ESMCAUSE SMALLINT,
> CTXTSTPCAUSE SMALLINT,
> CTXTMODCAUSE SMALLINT,
> S1RELCAUSE SMALLINT,
> AUTHREQOFFSET SMALLINT,
> AUTHRESOFFSET SMALLINT,
> SECUCMDOFFSET SMALLINT,
> SECUCPLOFFSET SMALLINT,
> CTXTSTPREQOFFSET SMALLINT,
> CTXTSTPRSPOFFSET SMALLINT,
> PAGINGRSPOFFSET SMALLINT,
> CTXTMODREQOFFSETINT,
> CTXTMODRSPOFFSETINT,
> S1RELOFFSET INT,
> INITREQERABNUM SMALLINT,
> INITSUCERABNUM SMALLINT,
> STPREQERABNUM SMALLINT,
> STPSUCERABNUM SMALLINT,
> MODREQERABNUM SMALLINT,
> MODSUCERABNUM SMALLINT,
> CTXTSTPSTATUS SMALLINT,
> CTXTMODSTATUS SMALLINT,
> AUTHSTATUS SMALLINT,
> SECUSTATUS SMALLINT,
> CAUSE1 SMALLINT,
> CAUSE2 SMALLINT,
> OFFSET1 INT,
> OFFSET2 INT,
> CALLINGNUM VARCHAR(26),
> CALLEDNUM VARCHAR(26),
> SMCNUMBER VARCHAR(26),
> ATAC SMALLINT,
> AECIINT,
> UCUESRVCCSUPPORTSMALLINT,
> EVENTCAUSETYPE SMALLINT,
> REQEVENTCAUSETYPE SMALLINT,
> ENBID SMALLINT,
> ENBMID SMALLINT,
> MMEID SMALLINT,
> MMEMID SMALLINT,
> AREAID SMALLINT,
> TAC VARCHAR(8),
> UETYPEID SMALLINT,
> TYPEID SMALLINT,
> MANUFACTURERID SMALLINT,
> RECVTIMEtimestamp,
> REGIONID SMALLINT,
> XDRNUMBER SMALLINT,
> SESSIONQCI SMALLINT
> ) LOCATION
> ('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
> FORMAT 'TEXT' (DELIMITER = E'\t');
> select * from DR_S1APP2P_TDR_20160720 limit 10;
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> ** 错误 **
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> SQL 状态: XX000
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goden Yao updated HAWQ-981:
---
Component/s: PXF
> create PXF External tables in HAWQ,Query error
> ---
>
> Key: HAWQ-981
> URL: https://issues.apache.org/jira/browse/HAWQ-981
> Project: Apache HAWQ
> Issue Type: Bug
> Components: PXF
>Affects Versions: 2.0.0.0-incubating
>Reporter: litiebiao
>Assignee: Lei Chang
> Fix For: backlog
>
>
> create EXTERNAL table DR_S1APP2P_TDR_20160720(
> PROTOCOLID SMALLINT,
> GLOBALIDNUMERIC(22),
> SESSIONID NUMERIC(22),
> CDRID NUMERIC(22),
> XDRTYPE SMALLINT,
> IMSIVARCHAR(16),
> IMEIVARCHAR(26),
> MSISDN VARCHAR(26),
> EVENTID SMALLINT,
> BTIME timestamp,
> ETIME timestamp,
> EVENTRESULT SMALLINT,
> EVENTCAUSE SMALLINT,
> REQUESTCAUSE SMALLINT,
> EVENTTYPE SMALLINT,
> EVENTTYPE1 SMALLINT,
> MMEADDRESS VARCHAR(40),
> ENBADDRESS VARCHAR(40),
> MMEPORT SMALLINT,
> ENBPORT SMALLINT,
> MMES1APUEID INT,
> ENBS1APUEID INT,
> MMEGRPID SMALLINT,
> MMECODE SMALLINT,
> MTMSI VARCHAR(8),
> OLDGUTITYPE SMALLINT,
> OLDMMEGRPIDSMALLINT,
> OLDMMECODE SMALLINT,
> OLDMTMSIVARCHAR(8),
> TMSIVARCHAR(8),
> UEIPV4ADDR VARCHAR(40),
> UEIPV6ADDR VARCHAR(40),
> ETAC SMALLINT,
> PEERTAC SMALLINT,
> ECI INT,
> PEERECI INT,
> LACSMALLINT,
> OLDLAC SMALLINT,
> CSFBRESULT SMALLINT,
> NASPROCFLAG SMALLINT,
> S1APPROCFLAGSMALLINT,
> ERABFLAGSMALLINT,
> PAGINGTYPE SMALLINT,
> VOICEDOMAIN SMALLINT,
> PAGINGDOMAINSMALLINT,
> UECENTRIC SMALLINT,
> VOPSOPT SMALLINT,
> EMMCAUSE SMALLINT,
> ESMCAUSE SMALLINT,
> CTXTSTPCAUSE SMALLINT,
> CTXTMODCAUSE SMALLINT,
> S1RELCAUSE SMALLINT,
> AUTHREQOFFSET SMALLINT,
> AUTHRESOFFSET SMALLINT,
> SECUCMDOFFSET SMALLINT,
> SECUCPLOFFSET SMALLINT,
> CTXTSTPREQOFFSET SMALLINT,
> CTXTSTPRSPOFFSET SMALLINT,
> PAGINGRSPOFFSET SMALLINT,
> CTXTMODREQOFFSETINT,
> CTXTMODRSPOFFSETINT,
> S1RELOFFSET INT,
> INITREQERABNUM SMALLINT,
> INITSUCERABNUM SMALLINT,
> STPREQERABNUM SMALLINT,
> STPSUCERABNUM SMALLINT,
> MODREQERABNUM SMALLINT,
> MODSUCERABNUM SMALLINT,
> CTXTSTPSTATUS SMALLINT,
> CTXTMODSTATUS SMALLINT,
> AUTHSTATUS SMALLINT,
> SECUSTATUS SMALLINT,
> CAUSE1 SMALLINT,
> CAUSE2 SMALLINT,
> OFFSET1 INT,
> OFFSET2 INT,
> CALLINGNUM VARCHAR(26),
> CALLEDNUM VARCHAR(26),
> SMCNUMBER VARCHAR(26),
> ATAC SMALLINT,
> AECIINT,
> UCUESRVCCSUPPORTSMALLINT,
> EVENTCAUSETYPE SMALLINT,
> REQEVENTCAUSETYPE SMALLINT,
> ENBID SMALLINT,
> ENBMID SMALLINT,
> MMEID SMALLINT,
> MMEMID SMALLINT,
> AREAID SMALLINT,
> TAC VARCHAR(8),
> UETYPEID SMALLINT,
> TYPEID SMALLINT,
> MANUFACTURERID SMALLINT,
> RECVTIMEtimestamp,
> REGIONID SMALLINT,
> XDRNUMBER SMALLINT,
> SESSIONQCI SMALLINT
> ) LOCATION
> ('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
> FORMAT 'TEXT' (DELIMITER = E'\t');
> select * from DR_S1APP2P_TDR_20160720 limit 10;
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> ** 错误 **
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> SQL 状态: XX000
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412125#comment-15412125
]
Goden Yao commented on HAWQ-981:
which version did you use ? (2.0.0.0-incubating or latest in master)
PXF is deployed on 51200 port, try to change port to 51200 in the location
string.
> create PXF External tables in HAWQ,Query error
> ---
>
> Key: HAWQ-981
> URL: https://issues.apache.org/jira/browse/HAWQ-981
> Project: Apache HAWQ
> Issue Type: Bug
> Components: PXF
>Affects Versions: 2.0.0.0-incubating
>Reporter: litiebiao
>Assignee: Goden Yao
> Fix For: backlog
>
>
> {code}
> CREATE EXTERNAL table DR_S1APP2P_TDR_20160720(
> PROTOCOLID SMALLINT,
> GLOBALIDNUMERIC(22),
> SESSIONID NUMERIC(22),
> CDRID NUMERIC(22),
> XDRTYPE SMALLINT,
> IMSIVARCHAR(16),
> IMEIVARCHAR(26),
> MSISDN VARCHAR(26),
> EVENTID SMALLINT,
> BTIME timestamp,
> ETIME timestamp,
> EVENTRESULT SMALLINT,
> EVENTCAUSE SMALLINT,
> REQUESTCAUSE SMALLINT,
> EVENTTYPE SMALLINT,
> EVENTTYPE1 SMALLINT,
> MMEADDRESS VARCHAR(40),
> ENBADDRESS VARCHAR(40),
> MMEPORT SMALLINT,
> ENBPORT SMALLINT,
> MMES1APUEID INT,
> ENBS1APUEID INT,
> MMEGRPID SMALLINT,
> MMECODE SMALLINT,
> MTMSI VARCHAR(8),
> OLDGUTITYPE SMALLINT,
> OLDMMEGRPIDSMALLINT,
> OLDMMECODE SMALLINT,
> OLDMTMSIVARCHAR(8),
> TMSIVARCHAR(8),
> UEIPV4ADDR VARCHAR(40),
> UEIPV6ADDR VARCHAR(40),
> ETAC SMALLINT,
> PEERTAC SMALLINT,
> ECI INT,
> PEERECI INT,
> LACSMALLINT,
> OLDLAC SMALLINT,
> CSFBRESULT SMALLINT,
> NASPROCFLAG SMALLINT,
> S1APPROCFLAGSMALLINT,
> ERABFLAGSMALLINT,
> PAGINGTYPE SMALLINT,
> VOICEDOMAIN SMALLINT,
> PAGINGDOMAINSMALLINT,
> UECENTRIC SMALLINT,
> VOPSOPT SMALLINT,
> EMMCAUSE SMALLINT,
> ESMCAUSE SMALLINT,
> CTXTSTPCAUSE SMALLINT,
> CTXTMODCAUSE SMALLINT,
> S1RELCAUSE SMALLINT,
> AUTHREQOFFSET SMALLINT,
> AUTHRESOFFSET SMALLINT,
> SECUCMDOFFSET SMALLINT,
> SECUCPLOFFSET SMALLINT,
> CTXTSTPREQOFFSET SMALLINT,
> CTXTSTPRSPOFFSET SMALLINT,
> PAGINGRSPOFFSET SMALLINT,
> CTXTMODREQOFFSETINT,
> CTXTMODRSPOFFSETINT,
> S1RELOFFSET INT,
> INITREQERABNUM SMALLINT,
> INITSUCERABNUM SMALLINT,
> STPREQERABNUM SMALLINT,
> STPSUCERABNUM SMALLINT,
> MODREQERABNUM SMALLINT,
> MODSUCERABNUM SMALLINT,
> CTXTSTPSTATUS SMALLINT,
> CTXTMODSTATUS SMALLINT,
> AUTHSTATUS SMALLINT,
> SECUSTATUS SMALLINT,
> CAUSE1 SMALLINT,
> CAUSE2 SMALLINT,
> OFFSET1 INT,
> OFFSET2 INT,
> CALLINGNUM VARCHAR(26),
> CALLEDNUM VARCHAR(26),
> SMCNUMBER VARCHAR(26),
> ATAC SMALLINT,
> AECIINT,
> UCUESRVCCSUPPORTSMALLINT,
> EVENTCAUSETYPE SMALLINT,
> REQEVENTCAUSETYPE SMALLINT,
> ENBID SMALLINT,
> ENBMID SMALLINT,
> MMEID SMALLINT,
> MMEMID SMALLINT,
> AREAID SMALLINT,
> TAC VARCHAR(8),
> UETYPEID SMALLINT,
> TYPEID SMALLINT,
> MANUFACTURERID SMALLINT,
> RECVTIMEtimestamp,
> REGIONID SMALLINT,
> XDRNUMBER SMALLINT,
> SESSIONQCI SMALLINT
> ) LOCATION
> ('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
> FORMAT 'TEXT' (DELIMITER = E'\t');
> select * from DR_S1APP2P_TDR_20160720 limit 10;
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> ** 错误 **
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> SQL 状态: XX000
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goden Yao reassigned HAWQ-981:
--
Assignee: Goden Yao (was: Lei Chang)
> create PXF External tables in HAWQ,Query error
> ---
>
> Key: HAWQ-981
> URL: https://issues.apache.org/jira/browse/HAWQ-981
> Project: Apache HAWQ
> Issue Type: Bug
> Components: PXF
>Affects Versions: 2.0.0.0-incubating
>Reporter: litiebiao
>Assignee: Goden Yao
> Fix For: backlog
>
>
> {code}
> CREATE EXTERNAL table DR_S1APP2P_TDR_20160720(
> PROTOCOLID SMALLINT,
> GLOBALIDNUMERIC(22),
> SESSIONID NUMERIC(22),
> CDRID NUMERIC(22),
> XDRTYPE SMALLINT,
> IMSIVARCHAR(16),
> IMEIVARCHAR(26),
> MSISDN VARCHAR(26),
> EVENTID SMALLINT,
> BTIME timestamp,
> ETIME timestamp,
> EVENTRESULT SMALLINT,
> EVENTCAUSE SMALLINT,
> REQUESTCAUSE SMALLINT,
> EVENTTYPE SMALLINT,
> EVENTTYPE1 SMALLINT,
> MMEADDRESS VARCHAR(40),
> ENBADDRESS VARCHAR(40),
> MMEPORT SMALLINT,
> ENBPORT SMALLINT,
> MMES1APUEID INT,
> ENBS1APUEID INT,
> MMEGRPID SMALLINT,
> MMECODE SMALLINT,
> MTMSI VARCHAR(8),
> OLDGUTITYPE SMALLINT,
> OLDMMEGRPIDSMALLINT,
> OLDMMECODE SMALLINT,
> OLDMTMSIVARCHAR(8),
> TMSIVARCHAR(8),
> UEIPV4ADDR VARCHAR(40),
> UEIPV6ADDR VARCHAR(40),
> ETAC SMALLINT,
> PEERTAC SMALLINT,
> ECI INT,
> PEERECI INT,
> LACSMALLINT,
> OLDLAC SMALLINT,
> CSFBRESULT SMALLINT,
> NASPROCFLAG SMALLINT,
> S1APPROCFLAGSMALLINT,
> ERABFLAGSMALLINT,
> PAGINGTYPE SMALLINT,
> VOICEDOMAIN SMALLINT,
> PAGINGDOMAINSMALLINT,
> UECENTRIC SMALLINT,
> VOPSOPT SMALLINT,
> EMMCAUSE SMALLINT,
> ESMCAUSE SMALLINT,
> CTXTSTPCAUSE SMALLINT,
> CTXTMODCAUSE SMALLINT,
> S1RELCAUSE SMALLINT,
> AUTHREQOFFSET SMALLINT,
> AUTHRESOFFSET SMALLINT,
> SECUCMDOFFSET SMALLINT,
> SECUCPLOFFSET SMALLINT,
> CTXTSTPREQOFFSET SMALLINT,
> CTXTSTPRSPOFFSET SMALLINT,
> PAGINGRSPOFFSET SMALLINT,
> CTXTMODREQOFFSETINT,
> CTXTMODRSPOFFSETINT,
> S1RELOFFSET INT,
> INITREQERABNUM SMALLINT,
> INITSUCERABNUM SMALLINT,
> STPREQERABNUM SMALLINT,
> STPSUCERABNUM SMALLINT,
> MODREQERABNUM SMALLINT,
> MODSUCERABNUM SMALLINT,
> CTXTSTPSTATUS SMALLINT,
> CTXTMODSTATUS SMALLINT,
> AUTHSTATUS SMALLINT,
> SECUSTATUS SMALLINT,
> CAUSE1 SMALLINT,
> CAUSE2 SMALLINT,
> OFFSET1 INT,
> OFFSET2 INT,
> CALLINGNUM VARCHAR(26),
> CALLEDNUM VARCHAR(26),
> SMCNUMBER VARCHAR(26),
> ATAC SMALLINT,
> AECIINT,
> UCUESRVCCSUPPORTSMALLINT,
> EVENTCAUSETYPE SMALLINT,
> REQEVENTCAUSETYPE SMALLINT,
> ENBID SMALLINT,
> ENBMID SMALLINT,
> MMEID SMALLINT,
> MMEMID SMALLINT,
> AREAID SMALLINT,
> TAC VARCHAR(8),
> UETYPEID SMALLINT,
> TYPEID SMALLINT,
> MANUFACTURERID SMALLINT,
> RECVTIMEtimestamp,
> REGIONID SMALLINT,
> XDRNUMBER SMALLINT,
> SESSIONQCI SMALLINT
> ) LOCATION
> ('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
> FORMAT 'TEXT' (DELIMITER = E'\t');
> select * from DR_S1APP2P_TDR_20160720 limit 10;
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> ** 错误 **
> ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
> to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
> SQL 状态: XX000
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-981) create PXF External tables in HAWQ,Query error
[
https://issues.apache.org/jira/browse/HAWQ-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Goden Yao updated HAWQ-981:
---
Description:
{code}
CREATE EXTERNAL table DR_S1APP2P_TDR_20160720(
PROTOCOLID SMALLINT,
GLOBALIDNUMERIC(22),
SESSIONID NUMERIC(22),
CDRID NUMERIC(22),
XDRTYPE SMALLINT,
IMSIVARCHAR(16),
IMEIVARCHAR(26),
MSISDN VARCHAR(26),
EVENTID SMALLINT,
BTIME timestamp,
ETIME timestamp,
EVENTRESULT SMALLINT,
EVENTCAUSE SMALLINT,
REQUESTCAUSE SMALLINT,
EVENTTYPE SMALLINT,
EVENTTYPE1 SMALLINT,
MMEADDRESS VARCHAR(40),
ENBADDRESS VARCHAR(40),
MMEPORT SMALLINT,
ENBPORT SMALLINT,
MMES1APUEID INT,
ENBS1APUEID INT,
MMEGRPID SMALLINT,
MMECODE SMALLINT,
MTMSI VARCHAR(8),
OLDGUTITYPE SMALLINT,
OLDMMEGRPIDSMALLINT,
OLDMMECODE SMALLINT,
OLDMTMSIVARCHAR(8),
TMSIVARCHAR(8),
UEIPV4ADDR VARCHAR(40),
UEIPV6ADDR VARCHAR(40),
ETAC SMALLINT,
PEERTAC SMALLINT,
ECI INT,
PEERECI INT,
LACSMALLINT,
OLDLAC SMALLINT,
CSFBRESULT SMALLINT,
NASPROCFLAG SMALLINT,
S1APPROCFLAGSMALLINT,
ERABFLAGSMALLINT,
PAGINGTYPE SMALLINT,
VOICEDOMAIN SMALLINT,
PAGINGDOMAINSMALLINT,
UECENTRIC SMALLINT,
VOPSOPT SMALLINT,
EMMCAUSE SMALLINT,
ESMCAUSE SMALLINT,
CTXTSTPCAUSE SMALLINT,
CTXTMODCAUSE SMALLINT,
S1RELCAUSE SMALLINT,
AUTHREQOFFSET SMALLINT,
AUTHRESOFFSET SMALLINT,
SECUCMDOFFSET SMALLINT,
SECUCPLOFFSET SMALLINT,
CTXTSTPREQOFFSET SMALLINT,
CTXTSTPRSPOFFSET SMALLINT,
PAGINGRSPOFFSET SMALLINT,
CTXTMODREQOFFSETINT,
CTXTMODRSPOFFSETINT,
S1RELOFFSET INT,
INITREQERABNUM SMALLINT,
INITSUCERABNUM SMALLINT,
STPREQERABNUM SMALLINT,
STPSUCERABNUM SMALLINT,
MODREQERABNUM SMALLINT,
MODSUCERABNUM SMALLINT,
CTXTSTPSTATUS SMALLINT,
CTXTMODSTATUS SMALLINT,
AUTHSTATUS SMALLINT,
SECUSTATUS SMALLINT,
CAUSE1 SMALLINT,
CAUSE2 SMALLINT,
OFFSET1 INT,
OFFSET2 INT,
CALLINGNUM VARCHAR(26),
CALLEDNUM VARCHAR(26),
SMCNUMBER VARCHAR(26),
ATAC SMALLINT,
AECIINT,
UCUESRVCCSUPPORTSMALLINT,
EVENTCAUSETYPE SMALLINT,
REQEVENTCAUSETYPE SMALLINT,
ENBID SMALLINT,
ENBMID SMALLINT,
MMEID SMALLINT,
MMEMID SMALLINT,
AREAID SMALLINT,
TAC VARCHAR(8),
UETYPEID SMALLINT,
TYPEID SMALLINT,
MANUFACTURERID SMALLINT,
RECVTIMEtimestamp,
REGIONID SMALLINT,
XDRNUMBER SMALLINT,
SESSIONQCI SMALLINT
) LOCATION
('pxf://10.213.39.234:50070/apps/hbase/data/data/default/DR_S1APP2P_TDR_20160720?profile=HdfsTextSimple')
FORMAT 'TEXT' (DELIMITER = E'\t');
select * from DR_S1APP2P_TDR_20160720 limit 10;
ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect
to 10.213.39.234:50070; Connection timed out (libchurl.c:878)
** 错误 **
ERROR: remote component error (0) from '10.213.39.234:50070': Failed connect to
10.213.39.234:50070; Connection timed out (libchurl.c:878)
SQL 状态: XX000
{code}
was:
create EXTERNAL table DR_S1APP2P_TDR_20160720(
PROTOCOLID SMALLINT,
GLOBALIDNUMERIC(22),
SESSIONID NUMERIC(22),
CDRID NUMERIC(22),
XDRTYPE SMALLINT,
IMSIVARCHAR(16),
IMEIVARCHAR(26),
MSISDN VARCHAR(26),
EVENTID SMALLINT,
BTIME timestamp,
ETIME timestamp,
EVENTRESULT SMALLINT,
EVENTCAUSE SMALLINT,
REQUESTCAUSE SMALLINT,
EVENTTYPE SMALLINT,
EVENTTYPE1 SMALLINT,
MMEADDRESS VARCHAR(40),
ENBADDRESS VARCHAR(40),
MMEPORT SMALLINT,
ENBPORT SMALLINT,
MMES1APUEID INT,
ENBS1APUEID INT,
MMEGRPID SMALLINT,
MMECODE SMALLINT,
MTMSI VARCHAR(8),
OLDGUTITYPE SMALLINT,
OLDMMEGRPIDSMALLINT,
OLDMMECODE SMALLINT,
OLDMTMSIVARCHAR(8),
TMSIVARCHAR(8),
UEIPV4ADDR VARCHAR(40),
UEIPV6ADDR VARCHAR(40),
ETAC SMALLINT,
PEERTAC SMALLINT,
ECI INT,
PEERECI INT,
LACSMALLINT,
OLDLAC SMALLINT,
CSFBRESULT SMALLINT,
NASPROCFLAG SMALLINT,
S1APPROCFLAGSMALLINT,
ERABFLAGSMALLINT,
PAGINGTYPE SMALLINT,
VOICEDOMAIN SMALLINT,
PAGINGDOMAINSMALLINT,
UECENTRIC SMALLINT,
VOPSOPT SMALLINT,
EMMCAUSE SMALLINT,
ESMCAUSE SMALLINT,
CTXTSTPCAUSE SMALLINT,
CTXTMODCAUSE SMALLINT,
S1RELCAUSE SMALLINT,
AUTHREQOFFSET SMALLINT,
AUTHRESOFFSET SMALLINT,
SECUCMDOFFSET SMALLINT,
SECUCPLOFFSET SMALLINT,
CTXTSTPREQOFFSET SMALLINT,
CTXTSTPRSPOFFSET SMALLINT,
PAGINGRSPOFFSET SMALLINT,
CTXTMODREQOFFSETINT,
CTXTMODRSPOFFSETINT,
S1RELOFFSET INT,
INITREQERABNUM SMALLINT,
INITSUCERABNUM SMALLINT,
STPREQERABNUM SMALLINT,
STPSUCERABNUM SMALLINT,
MODREQERABNUM SMALLINT,
MODSUCERABNUM SMALLINT,
CTXTSTPSTATUS SMALLINT,
CTXTMODSTATUS SMALLINT,
AUTHSTATUS SMALLINT,
SECUSTATUS SMALLINT,
CAUSE1 SMALLINT,
CAUSE2 SMALLINT,
OFFSET1 INT,
OFFSET2 INT,
CALLINGNUM VARCHAR(26),
CALLEDNUM VARCHAR(26),
SMCNUMBER VARCHAR(26),
ATAC SMALL
[jira] [Assigned] (HAWQ-985) Add feature test for agg with groupingsets and null using new test framework
[ https://issues.apache.org/jira/browse/HAWQ-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhenglin tao reassigned HAWQ-985: - Assignee: zhenglin tao (was: Jiali Yao) > Add feature test for agg with groupingsets and null using new test framework > > > Key: HAWQ-985 > URL: https://issues.apache.org/jira/browse/HAWQ-985 > Project: Apache HAWQ > Issue Type: Sub-task > Components: Tests >Reporter: zhenglin tao >Assignee: zhenglin tao > Fix For: 2.0.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-985) Add feature test for agg with groupingsets and null using new test framework
zhenglin tao created HAWQ-985: - Summary: Add feature test for agg with groupingsets and null using new test framework Key: HAWQ-985 URL: https://issues.apache.org/jira/browse/HAWQ-985 Project: Apache HAWQ Issue Type: Sub-task Components: Tests Reporter: zhenglin tao Assignee: Jiali Yao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HAWQ-256) Integrate Security with Apache Ranger
[
https://issues.apache.org/jira/browse/HAWQ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411542#comment-15411542
]
Hubert Zhang edited comment on HAWQ-256 at 8/8/16 9:07 AM:
---
Agree. We can use JSON array to represent it.
{code}
{
“requestor” : “u1”,
[
{
“resource” : {“TABLE”: “t1”, “DATABASE”: “db1”},
“privilege” : [“select”, "insert"]
},
{
“resource” : {“TABLE”: “t2”, “DATABASE”: “db1”},
“privilege” : [“select”]
}
]
}
{code}
was (Author: hubertzhang):
Agree. We can use JSON array to represent it.
{
“requestor” : “u1”,
[
{
“resource” : {“TABLE”: “t1”, “DATABASE”: “db1”},
“privilege” : [“select”, "insert"]
},
{
“resource” : {“TABLE”: “t2”, “DATABASE”: “db1”},
“privilege” : [“select”]
}
]
}
> Integrate Security with Apache Ranger
> -
>
> Key: HAWQ-256
> URL: https://issues.apache.org/jira/browse/HAWQ-256
> Project: Apache HAWQ
> Issue Type: New Feature
> Components: PXF, Security
>Reporter: Michael Andre Pearce (IG)
>Assignee: Lili Ma
> Fix For: backlog
>
> Attachments: HAWQRangerSupportDesign.pdf
>
>
> Integrate security with Apache Ranger for a unified Hadoop security solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HAWQ-256) Integrate Security with Apache Ranger
[
https://issues.apache.org/jira/browse/HAWQ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411542#comment-15411542
]
Hubert Zhang commented on HAWQ-256:
---
Agree. We can use JSON array to represent it.
{
“requestor” : “u1”,
[
{
“resource” : {“TABLE”: “t1”, “DATABASE”: “db1”},
“privilege” : [“select”, "insert"]
},
{
“resource” : {“TABLE”: “t2”, “DATABASE”: “db1”},
“privilege” : [“select”]
}
]
}
> Integrate Security with Apache Ranger
> -
>
> Key: HAWQ-256
> URL: https://issues.apache.org/jira/browse/HAWQ-256
> Project: Apache HAWQ
> Issue Type: New Feature
> Components: PXF, Security
>Reporter: Michael Andre Pearce (IG)
>Assignee: Lili Ma
> Fix For: backlog
>
> Attachments: HAWQRangerSupportDesign.pdf
>
>
> Integrate security with Apache Ranger for a unified Hadoop security solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] incubator-hawq pull request #835: HAWQ-980. hawq does not handle guc value w...
Github user paul-guo- commented on a diff in the pull request:
https://github.com/apache/incubator-hawq/pull/835#discussion_r73841829
--- Diff: src/backend/cdb/executormgr.c ---
@@ -864,29 +864,42 @@ addOneOption(PQExpBufferData *buffer, struct
config_generic * guc)
{
struct config_string *sguc = (struct
config_string *) guc;
const char *str = *sguc->variable;
- int j,
- start,
- end;
- chartemp[1024];
+ unsigned int j, start, size;
+ char*temp;
- end = strlen(str);
+ size = 256;
+ temp = malloc(size + 8);
+ if (temp == NULL)
+ ereport(ERROR,
+
(errcode(ERRCODE_OUT_OF_MEMORY),
+errmsg("out of
memory")));
j = 0;
- for (start = 0; start < end; ++start)
+ for (start = 0; start < strlen(str); ++start)
{
- if (str[start] == ' ')
- continue;
+ if (j == size)
+ {
+ size *= 2;
+ temp = realloc(temp, size + 8);
+ if (temp == NULL)
--- End diff --
Yes. Need to take care of.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-hawq pull request #835: HAWQ-980. hawq does not handle guc value w...
Github user paul-guo- commented on a diff in the pull request:
https://github.com/apache/incubator-hawq/pull/835#discussion_r73841782
--- Diff: src/backend/cdb/executormgr.c ---
@@ -864,29 +864,42 @@ addOneOption(PQExpBufferData *buffer, struct
config_generic * guc)
{
struct config_string *sguc = (struct
config_string *) guc;
const char *str = *sguc->variable;
- int j,
- start,
- end;
- chartemp[1024];
+ unsigned int j, start, size;
+ char*temp;
- end = strlen(str);
+ size = 256;
--- End diff --
256 does not have special meaning. It is just a rough initial size so that
realloc() is seldom called.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (HAWQ-256) Integrate Security with Apache Ranger
[ https://issues.apache.org/jira/browse/HAWQ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411518#comment-15411518 ] Lili Ma commented on HAWQ-256: -- Another thing is for HAWQ sync with LDAP. By our investigation, HAWQ needs to run "create role" command for user registered in LDAP. [~teaandcoffee], do you think providing a script for this is acceptable? Or we need to create a backend process to do the user information sync automatically? cc [~wenlin] for this discussion too. Thanks > Integrate Security with Apache Ranger > - > > Key: HAWQ-256 > URL: https://issues.apache.org/jira/browse/HAWQ-256 > Project: Apache HAWQ > Issue Type: New Feature > Components: PXF, Security >Reporter: Michael Andre Pearce (IG) >Assignee: Lili Ma > Fix For: backlog > > Attachments: HAWQRangerSupportDesign.pdf > > > Integrate security with Apache Ranger for a unified Hadoop security solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HAWQ-256) Integrate Security with Apache Ranger
[
https://issues.apache.org/jira/browse/HAWQ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411509#comment-15411509
]
Lili Ma commented on HAWQ-256:
--
[~bosco],
Will you confirm with folks in Ranger team for the API? Thanks
For the API interface, the grant/revoke part, we just design the API
corresponding to SQL grant/revoke syntax.
For the check privilege part, I think your advise is sensible. We can provide
the function for multiple resource check in one time. What about we change it
to following format, say, allowing one requestor to check multiple resources,
and for single resource, allowing multiple operations check?
{code}
{
“requestor” : “u1”,
{
{
“resource” : {“TABLE”: “t1”, “DATABASE”: “db1”},
“privilege” : “select”, "insert"
},
{
“resource” : {“TABLE”: “t2”, “DATABASE”: “db1”},
“privilege” : “select”
}
}
}
{code}
[~hubertzhang], your thoughts?
> Integrate Security with Apache Ranger
> -
>
> Key: HAWQ-256
> URL: https://issues.apache.org/jira/browse/HAWQ-256
> Project: Apache HAWQ
> Issue Type: New Feature
> Components: PXF, Security
>Reporter: Michael Andre Pearce (IG)
>Assignee: Lili Ma
> Fix For: backlog
>
> Attachments: HAWQRangerSupportDesign.pdf
>
>
> Integrate security with Apache Ranger for a unified Hadoop security solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HAWQ-984) hawq config is too slow.
[ https://issues.apache.org/jira/browse/HAWQ-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Guo updated HAWQ-984: -- Description: I tried to set a simple guc value via "hawq config" on my centos virtual system, but it spends >6 seconds. I know "hawq config" just simple scp-update xml files to various nodes. This should have been very fast if network situation is fine (My test hawq system is all-in-one test environment so network latency is not an issue.) I expect this is done on my test system (just one seg node) in < 1 second. But actually the time is: $ time hawq config -c lc_messages -v en_US.UTF-8 GUC lc_messages already exist in hawq-site.xml Update it with value: en_US.UTF-8 GUC : lc_messages Value : en_US.UTF-8 real0m6.363s user0m0.943s sys 0m1.258s I quickly monitored the processes when running "hawq config", it seems that the scp command finishes very early and adding print debug code in python file gpscp shows that the code in it finishes also very early. I'm not sure if anyone sees that long like my case (my system is probably quite mangled after dev and test). I roughly traced the python stack. I suspect there is something wrong in python or we are not using related module well or we should replace modules. I just checked "hawq config" but it is possible other CLI suffers from this also. was: I tried to set a simple guc value via "hawq config" on my centos virtual system, but it spends >6 seconds. I know "hawq config" just simple scp-update xml files to various nodes. This should have been very fast if network situation is fine (My test hawq system is all-in-one test environment so network latency is not an issue.) I expect this is done on my test system (just one seg node) in < 1 second. But actually the time is: $ time hawq config -c lc_messages -v en_US.UTF-8 GUC lc_messages already exist in hawq-site.xml Update it with value: en_US.UTF-8 GUC : lc_messages Value : en_US.UTF-8 real0m6.363s user0m0.943s sys 0m1.258s I quickly monitored the processes when running "hawq config", it seems that the scp command finishes very early and adding print debug code in python file gpscp shows that the code in it finishes also very early. I'm not sure if anyone sees that long like my case (my system is probably quite mangled after dev and test). I roughly traced the python stack. I suspect there is something wrong in python or we are not using related module well or we should replace modules. At least to my limited python knowledge, python subprocess (A suspicious culprit) is quite tricky. I just checked "hawq config" but it is possible other CLI suffers from this also. > hawq config is too slow. > > > Key: HAWQ-984 > URL: https://issues.apache.org/jira/browse/HAWQ-984 > Project: Apache HAWQ > Issue Type: Bug > Components: Command Line Tools >Reporter: Paul Guo >Assignee: Lei Chang > Fix For: backlog > > > I tried to set a simple guc value via "hawq config" on my centos > virtual system, but it spends >6 seconds. I know "hawq config" just > simple scp-update xml files to various nodes. This should have > been very fast if network situation is fine (My test hawq system is all-in-one > test environment so network latency is not an issue.) > I expect this is done on my test system (just one seg node) in < 1 second. > But actually the time is: > $ time hawq config -c lc_messages -v en_US.UTF-8 > GUC lc_messages already exist in hawq-site.xml > Update it with value: en_US.UTF-8 > GUC : lc_messages > Value : en_US.UTF-8 > real 0m6.363s > user 0m0.943s > sys 0m1.258s > I quickly monitored the processes when running "hawq config", > it seems that the scp command finishes very early and adding > print debug code in python file gpscp shows that the code in it > finishes also very early. > I'm not sure if anyone sees that long like my case (my system > is probably quite mangled after dev and test). I roughly traced > the python stack. I suspect there is something wrong in python > or we are not using related module well or we should replace modules. > I just checked "hawq config" but it is possible other CLI suffers from this > also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HAWQ-984) hawq config is too slow.
[ https://issues.apache.org/jira/browse/HAWQ-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Guo updated HAWQ-984: -- Fix Version/s: backlog > hawq config is too slow. > > > Key: HAWQ-984 > URL: https://issues.apache.org/jira/browse/HAWQ-984 > Project: Apache HAWQ > Issue Type: Bug > Components: Command Line Tools >Reporter: Paul Guo >Assignee: Lei Chang > Fix For: backlog > > > I tried to set a simple guc value via "hawq config" on my centos > virtual system, but it spends >6 seconds. I know "hawq config" just > simple scp-update xml files to various nodes. This should have > been very fast if network situation is fine (My test hawq system is all-in-one > test environment so network latency is not an issue.) > I expect this is done on my test system (just one seg node) in < 1 second. > But actually the time is: > $ time hawq config -c lc_messages -v en_US.UTF-8 > GUC lc_messages already exist in hawq-site.xml > Update it with value: en_US.UTF-8 > GUC : lc_messages > Value : en_US.UTF-8 > real 0m6.363s > user 0m0.943s > sys 0m1.258s > I quickly monitored the processes when running "hawq config", > it seems that the scp command finishes very early and adding > print debug code in python file gpscp shows that the code in it > finishes also very early. > I'm not sure if anyone sees that long like my case (my system > is probably quite mangled after dev and test). I roughly traced > the python stack. I suspect there is something wrong in python > or we are not using related module well or we should replace modules. > At least to my limited python knowledge, python subprocess > (A suspicious culprit) is quite tricky. > I just checked "hawq config" but it is possible other CLI suffers from this > also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HAWQ-984) hawq config is too slow.
Paul Guo created HAWQ-984: - Summary: hawq config is too slow. Key: HAWQ-984 URL: https://issues.apache.org/jira/browse/HAWQ-984 Project: Apache HAWQ Issue Type: Bug Components: Command Line Tools Reporter: Paul Guo Assignee: Lei Chang I tried to set a simple guc value via "hawq config" on my centos virtual system, but it spends >6 seconds. I know "hawq config" just simple scp-update xml files to various nodes. This should have been very fast if network situation is fine (My test hawq system is all-in-one test environment so network latency is not an issue.) I expect this is done on my test system (just one seg node) in < 1 second. But actually the time is: $ time hawq config -c lc_messages -v en_US.UTF-8 GUC lc_messages already exist in hawq-site.xml Update it with value: en_US.UTF-8 GUC : lc_messages Value : en_US.UTF-8 real0m6.363s user0m0.943s sys 0m1.258s I quickly monitored the processes when running "hawq config", it seems that the scp command finishes very early and adding print debug code in python file gpscp shows that the code in it finishes also very early. I'm not sure if anyone sees that long like my case (my system is probably quite mangled after dev and test). I roughly traced the python stack. I suspect there is something wrong in python or we are not using related module well or we should replace modules. At least to my limited python knowledge, python subprocess (A suspicious culprit) is quite tricky. I just checked "hawq config" but it is possible other CLI suffers from this also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
