postgres-xc-developers — Postgres-XC hackers and developers

Re: [Postgres-xc-developers] Running regression test.

[Koichi S. <koi...@gm...>]

Thank you Tomonori and Abbas;

To run make installcheck, we need to setup PG* environemnt for the
installation/configuration.   To make it simpler, we may need some
improvement in the regression as well (to specify target port and host).

Regards;

----------
Koichi Suzuki


2013/7/8 Abbas Butt <abb...@en...>

>
>
> On Mon, Jul 8, 2013 at 12:55 PM, Tomonari Katsumata <
> kat...@po...> wrote:
>
>> Hi,
>>
>> I've tried regression test with Postgres-XC master, it didn't work.
>> Now, I've tried it with 1.1beta, but it didn't work too.
>>
>> =========================
>> 58 of 153 tests failed.
>> =========================
>>
>> My test environment is below.
>> ----
>> server : CentOS 6.4 x86_64 on VMWare player
>> cpu : Intel(R) Core(TM) i3-2370M CPU @2.40GHz(1core assigned)
>> memory : 256MB
>> dbms : Postgres-XC 1.1beta
>> ----
>> all components are in one server.
>> (please see "pgxc_ctl.conf")
>>
>> And the procedure is below.
>> ============================================
>> 1. build Postgres-XC and pgxc_ctl
>>
>> ./configure --enable-debug CFLAGS='-O0'
>> make
>> sudo make install
>> cd contrib/pgxc_ctl
>> make
>> sudo make install
>>
>> 2. init Postgres-XC with pgxc_ctl
>> pgxc_ctl init all
>>
>> 3. start regression test
>> make installcheck
>> ============================================
>> Did I do something wrong ??
>>
>
> No.
>
>
>>
>> The log messages says Postgres-XC (coordinator) crashed when
>> processing xmlmap test.
>> This is same scenario with the behavior of master.
>> ----
>> LOG: server process (PID 14567) was terminated by signal 11:
>> Segmentation fault
>> DETAIL: Failed process was running: DECLARE xc CURSOR WITH HOLD FOR
>> SELECT * FROM testxmlschema.test1 ORDER BY 1, 2;
>> LOG: terminating any other active server processes
>> WARNING: terminating connection because of crash of another server process
>> DETAIL: The postmaster has commanded this server process to roll back
>> the current transaction and exit, because another server process exited
>> abnormally and possibly corrupted shared memory.
>> HINT: In a moment you should be able to reconnect to the database and
>> repeat your command.
>> LOG: archiver process (PID 13432) exited with exit code 1
>> LOG: all server processes terminated; reinitializing
>> FATAL: the database system is in recovery mode
>> LOG: database system was interrupted; last known up at 2013-07-07
>> 22:29:16 PDT
>> LOG: database system was not properly shut down; automatic recovery in
>> progress
>> FATAL: the database system is in recovery mode
>> ----
>>
>> Is this a problem or not problem ?
>>
>
> This is a problem.
>
>
>> Anybody runs all regression test cases ?
>>
>
> We do, but not with 1 coordinator and 1 datanode like you did.
>
>
>> What should I do to run all ?
>>
>
> I was able to reproduce the crash. Actually there are multiple crashes.
> The crash happens when we run regression with 1 coordinator and 1 datanode
> that happens to be primary.
>
> The first crash (an assertion failure on the datanode) can be reproduced
> using this test case (aggregates.sql)
>
> create table varchar_tbl( f1 character varying(4) );
> insert into varchar_tbl values('a'), ('ab'), ('abcd'), ('abcd');
> select string_agg(distinct f1, ',' order by f1) from varchar_tbl;
>
> It would cause a datanode crash
>
> TRAP: FailedAssertion("!(AggCheckCallContext(fcinfo, ((void *)0)))", File:
> "varlena.c", Line: 3668)
>
> The second crash (an assertion failure on coordinator) can be reproduced
> using this test case (xmlmap.sql)
> CREATE SCHEMA testxmlschema;
> CREATE TABLE testxmlschema.test1 (a int, b text);
> INSERT INTO testxmlschema.test1 VALUES (1, 'one'), (2, 'two'), (-1, null);
>
>
> DECLARE xc CURSOR WITH HOLD FOR SELECT * FROM testxmlschema.test1 ORDER BY
> 1, 2;
>
> TRAP: BadArgument("!(((header->context) != ((void *)0) && (((((const
> Node*)((header->context)))->type) == T_AllocSetContext))))", File:
> "mcxt.c", Line: 660)
>
> To be able to run the regression with 1 coordinator and 1 datanode we need
> to fix these two issues first and then see whether we have any additional
> case to fix.
>
> Special thanks to Tomonari for the efforts that led to discovery of these
> errors.
>
> I am going to spend some time to try and fix these errors. Any other
> suggestion is welcome.
>
>
>
>>
>> regards,
>> ----------
>> NTT Software Corporation
>> Tomonari Katsumata
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>
>
> --
> --
> *Abbas*
>  Architect
>
> Ph: 92.334.5100153
>  Skype ID: gabbasb
> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
> *
> Follow us on Twitter*
> @EnterpriseDB
>
> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

Re: [Postgres-xc-developers] Running regression test.

[Abbas B. <abb...@en...>]

On Mon, Jul 8, 2013 at 12:55 PM, Tomonari Katsumata <
kat...@po...> wrote:

> Hi,
>
> I've tried regression test with Postgres-XC master, it didn't work.
> Now, I've tried it with 1.1beta, but it didn't work too.
>
> =========================
> 58 of 153 tests failed.
> =========================
>
> My test environment is below.
> ----
> server : CentOS 6.4 x86_64 on VMWare player
> cpu : Intel(R) Core(TM) i3-2370M CPU @2.40GHz(1core assigned)
> memory : 256MB
> dbms : Postgres-XC 1.1beta
> ----
> all components are in one server.
> (please see "pgxc_ctl.conf")
>
> And the procedure is below.
> ============================================
> 1. build Postgres-XC and pgxc_ctl
>
> ./configure --enable-debug CFLAGS='-O0'
> make
> sudo make install
> cd contrib/pgxc_ctl
> make
> sudo make install
>
> 2. init Postgres-XC with pgxc_ctl
> pgxc_ctl init all
>
> 3. start regression test
> make installcheck
> ============================================
> Did I do something wrong ??
>

No.


>
> The log messages says Postgres-XC (coordinator) crashed when
> processing xmlmap test.
> This is same scenario with the behavior of master.
> ----
> LOG: server process (PID 14567) was terminated by signal 11:
> Segmentation fault
> DETAIL: Failed process was running: DECLARE xc CURSOR WITH HOLD FOR
> SELECT * FROM testxmlschema.test1 ORDER BY 1, 2;
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another server process
> DETAIL: The postmaster has commanded this server process to roll back
> the current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT: In a moment you should be able to reconnect to the database and
> repeat your command.
> LOG: archiver process (PID 13432) exited with exit code 1
> LOG: all server processes terminated; reinitializing
> FATAL: the database system is in recovery mode
> LOG: database system was interrupted; last known up at 2013-07-07
> 22:29:16 PDT
> LOG: database system was not properly shut down; automatic recovery in
> progress
> FATAL: the database system is in recovery mode
> ----
>
> Is this a problem or not problem ?
>

This is a problem.


> Anybody runs all regression test cases ?
>

We do, but not with 1 coordinator and 1 datanode like you did.


> What should I do to run all ?
>

I was able to reproduce the crash. Actually there are multiple crashes. The
crash happens when we run regression with 1 coordinator and 1 datanode that
happens to be primary.

The first crash (an assertion failure on the datanode) can be reproduced
using this test case (aggregates.sql)

create table varchar_tbl( f1 character varying(4) );
insert into varchar_tbl values('a'), ('ab'), ('abcd'), ('abcd');
select string_agg(distinct f1, ',' order by f1) from varchar_tbl;

It would cause a datanode crash

TRAP: FailedAssertion("!(AggCheckCallContext(fcinfo, ((void *)0)))", File:
"varlena.c", Line: 3668)

The second crash (an assertion failure on coordinator) can be reproduced
using this test case (xmlmap.sql)
CREATE SCHEMA testxmlschema;
CREATE TABLE testxmlschema.test1 (a int, b text);
INSERT INTO testxmlschema.test1 VALUES (1, 'one'), (2, 'two'), (-1, null);

DECLARE xc CURSOR WITH HOLD FOR SELECT * FROM testxmlschema.test1 ORDER BY
1, 2;

TRAP: BadArgument("!(((header->context) != ((void *)0) && (((((const
Node*)((header->context)))->type) == T_AllocSetContext))))", File:
"mcxt.c", Line: 660)

To be able to run the regression with 1 coordinator and 1 datanode we need
to fix these two issues first and then see whether we have any additional
case to fix.

Special thanks to Tomonari for the efforts that led to discovery of these
errors.

I am going to spend some time to try and fix these errors. Any other
suggestion is welcome.



>
> regards,
> ----------
> NTT Software Corporation
> Tomonari Katsumata
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
-- 
*Abbas*
 Architect

Ph: 92.334.5100153
 Skype ID: gabbasb
www.enterprisedb.co
<http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
*
Follow us on Twitter*
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars,
whitepapers<http://www.enterprisedb.com/resources-community>and
more<http://www.enterprisedb.com/resources-community>

[Postgres-xc-developers] Running regression test.

[Tomonari K. <kat...@po...>]

Hi,

I've tried regression test with Postgres-XC master, it didn't work.
Now, I've tried it with 1.1beta, but it didn't work too.

=========================
58 of 153 tests failed.
=========================

My test environment is below.
----
server : CentOS 6.4 x86_64 on VMWare player
cpu : Intel(R) Core(TM) i3-2370M CPU @2.40GHz(1core assigned)
memory : 256MB
dbms : Postgres-XC 1.1beta
----
all components are in one server.
(please see "pgxc_ctl.conf")

And the procedure is below.
============================================
1. build Postgres-XC and pgxc_ctl

./configure --enable-debug CFLAGS='-O0'
make
sudo make install
cd contrib/pgxc_ctl
make
sudo make install

2. init Postgres-XC with pgxc_ctl
pgxc_ctl init all

3. start regression test
make installcheck
============================================
Did I do something wrong ??

The log messages says Postgres-XC (coordinator) crashed when
processing xmlmap test.
This is same scenario with the behavior of master.
----
LOG: server process (PID 14567) was terminated by signal 11:
Segmentation fault
DETAIL: Failed process was running: DECLARE xc CURSOR WITH HOLD FOR
SELECT * FROM testxmlschema.test1 ORDER BY 1, 2;
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
LOG: archiver process (PID 13432) exited with exit code 1
LOG: all server processes terminated; reinitializing
FATAL: the database system is in recovery mode
LOG: database system was interrupted; last known up at 2013-07-07
22:29:16 PDT
LOG: database system was not properly shut down; automatic recovery in
progress
FATAL: the database system is in recovery mode
----

Is this a problem or not problem ?
Anybody runs all regression test cases ?
What should I do to run all ?

regards,
----------
NTT Software Corporation
Tomonari Katsumata

Re: [Postgres-xc-developers] Connection to Postgres XC cluster from Java

[Michael P. <mic...@gm...>]

On Mon, Jul 8, 2013 at 10:17 AM, 鈴木 幸市 <ko...@in...> wrote:
> Unfortunately, we don't have connection failover.   You may be able to use
> pgboucer for this purpose (sorry, I'm not pgboucer expert) or you may be
> able to use any other connection pooling tools which provides connection
> failover.
Like Postgres, there is no connection failover in XC, you'll need a
third-party software to manage that.

Note that you could use pgbouncer with a dns lookup to combine several
IP addresses that could be used in round-robin manner when
establishing connections. More info:
http://pgbouncer.projects.pgfoundry.org/doc/config.html#_location_parameters

HAProxy is more designed for load balancing and HA, perhaps it's worth
looking at it:
http://haproxy.1wt.eu/#desc
--
Michael

Re: [Postgres-xc-developers] Connection to Postgres XC cluster from Java

[鈴木 幸市 <ko...@in...>]

Unfortunately, we don't have connection failover.   You may be able to use pgboucer for this purpose (sorry, I'm not pgboucer expert) or you may be able to use any other connection pooling tools which provides connection failover. 

XC's situation is the same as vanilla PostgreSQL in this regard.

Regards;
---
Koichi Suzuki



On 2013/07/05, at 21:29, Adam Dec <ada...@gm...> wrote:

> Hi!
> 
> I woul like to connect to cluster using postgres Java drivers + JDBC API.
> Do you know any solutions to maintain connection failover in case that some of the coordinator (or the whole node ) will go down?
> 
> Regards,
> 
> Adam Dec
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

[Postgres-xc-developers] Connection to Postgres XC cluster from Java

[Adam D. <ada...@gm...>]

Hi!

I woul like to connect to cluster using postgres Java drivers + JDBC API.
Do you know any solutions to maintain connection failover in case that some
of the coordinator (or the whole node ) will go down?

Regards,

Adam Dec

[Postgres-xc-developers] Not doing any cleanup this time

[Michael P. <mic...@gm...>]

Hi all,

It looks that all the Postgres tags have been committed in XC's
repository once agsin. This is generated a lot of spam mail... Perhaps
this move was planned, but if it was not the case I am not planning to
do any manual cleanup this time.

Thanks,
--
Michael

Re: [Postgres-xc-developers] SRF not working ?

[Michael P. <mic...@gm...>]

On Fri, Jul 5, 2013 at 1:23 PM, Ashutosh Bapat
<ash...@en...> wrote:
>
>
>
> On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier <mic...@gm...>
> wrote:
>>
>> On Thu, Jul 4, 2013 at 7:07 PM, Pavan Deolasee <pav...@gm...>
>> wrote:
>> >
>> > On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier
>> > <mic...@gm...>
>> >> generate_series has never been fixed for hash tables as far as I
>> >> recall.
>> > Hmm.. that could well be the case. I am immensely surprised and
>> > disappointed
>> > if that's true though. IMHO any PostgreSQL user will most likely fire
>> > that
>> > statement soon after creating a table to populate test data. It does not
>> > sound nice if the very first statement errors out.
>> +1.
>>
>> > What stops us from supporting that, except of course lack of development
>> > time?
>> That and the fact that such exceptions have never been considered a
>> high priority, I suppose. generate_series is the particular case of an
>> immutable function that cannot be FQS'ed for a non-replicated table. I
>> might be wrong, but I think it worked correctly for roundrobin.
>>
>
> I don't agree that it's because of immutability. It has more to do with the
> VALUES_RTE in INSERT statement. Any INSERT statement that is inserting more
> than one value in the distributed table can not be FQSed. In case there are
> more than one value being INSERTED through an INSERT statement, there are
> two RTEs in the query, one for the relation where INSERT is happening, and
> other for the values. So, I had implemented a simple rule in FQS
> shippability - if there are more than one RTEs in INSERT statement, do not
> FQS it. But I am unable to locate this rule now. Looks like while
> implementing something else, the rule has disappeared. And, since we do not
> have test for it, we didn't notice it.
Yeah you are right, sorry. This is not related to the immutability but
to the fact that the distribution column is used for such an INSERT.
--
Michael

Re: [Postgres-xc-developers] SRF not working ?

[Ashutosh B. <ash...@en...>]

On Fri, Jul 5, 2013 at 10:03 AM, Pavan Deolasee <pav...@gm...>wrote:

>
>
>
> On Fri, Jul 5, 2013 at 9:53 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>>
>>
>>
>> On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier <
>> mic...@gm...> wrote:
>>
>>>
>>>
>>>
>> I don't agree that it's because of immutability. It has more to do with
>> the VALUES_RTE in INSERT statement. Any INSERT statement that is inserting
>> more than one value in the distributed table can not be FQSed. In case
>> there are more than one value being INSERTED through an INSERT statement,
>> there are two RTEs in the query, one for the relation where INSERT is
>> happening, and other for the values. So, I had implemented a simple rule in
>> FQS shippability - if there are more than one RTEs in INSERT statement, do
>> not FQS it. But I am unable to locate this rule now. Looks like while
>> implementing something else, the rule has disappeared. And, since we do not
>> have test for it, we didn't notice it.
>>
>>
>
>
> You mean this code in pgxcship.c ?
>
>  905
>  906             /* PGXCTODO: It should be possible to look at the Query
> and find out
>  907              * whether it can be completely evaluated on the Datanode
> just like SELECT
>  908              * queries. But we need to be careful while finding out
> the Datanodes to
>  909              * execute the query on, esp. for the result relations.
> If one happens to
>  910              * remove/change this restriction, make sure you change
>  911              * pgxc_FQS_get_relation_nodes appropriately.
>  912              * For now DMLs with single rtable entry are candidates
> for FQS
>  913              */
>  914             if (query->commandType != CMD_SELECT &&
> list_length(query->rtable) > 1)
>  915                 pgxc_set_shippability_reason(sc_context,
> SS_UNSUPPORTED_EXPR);
>
>
Ah, right. I was searching for CMD_INSERT so couldn't locate it. Yes, this
is stronger and better condition not to FQS any DML with more than one RTE.
I am not sure why it doesn't obey VALUES generate_series()? May it doesn't
show up as an RTE.


> BTW, I looked at the regression and I spotted at least one test case that
> use generate_series() to insert data in a distributed table but still does
> not fail. Its so because the test case uses a subquery to fire the insert.
> So a workaround to the failing query is:
>
> INSERT INTO testtbl SELECT generate_series(1,10000), 'foo';
>
> Thanks,
> Pavan
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company

Re: [Postgres-xc-developers] SRF not working ?

[Pavan D. <pav...@gm...>]

On Fri, Jul 5, 2013 at 9:53 AM, Ashutosh Bapat <
ash...@en...> wrote:

>
>
>
> On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier <mic...@gm...
> > wrote:
>
>>
>>
>>
> I don't agree that it's because of immutability. It has more to do with
> the VALUES_RTE in INSERT statement. Any INSERT statement that is inserting
> more than one value in the distributed table can not be FQSed. In case
> there are more than one value being INSERTED through an INSERT statement,
> there are two RTEs in the query, one for the relation where INSERT is
> happening, and other for the values. So, I had implemented a simple rule in
> FQS shippability - if there are more than one RTEs in INSERT statement, do
> not FQS it. But I am unable to locate this rule now. Looks like while
> implementing something else, the rule has disappeared. And, since we do not
> have test for it, we didn't notice it.
>
>


You mean this code in pgxcship.c ?

 905
 906             /* PGXCTODO: It should be possible to look at the Query
and find out
 907              * whether it can be completely evaluated on the Datanode
just like SELECT
 908              * queries. But we need to be careful while finding out
the Datanodes to
 909              * execute the query on, esp. for the result relations. If
one happens to
 910              * remove/change this restriction, make sure you change
 911              * pgxc_FQS_get_relation_nodes appropriately.
 912              * For now DMLs with single rtable entry are candidates
for FQS
 913              */
 914             if (query->commandType != CMD_SELECT &&
list_length(query->rtable) > 1)
 915                 pgxc_set_shippability_reason(sc_context,
SS_UNSUPPORTED_EXPR);

BTW, I looked at the regression and I spotted at least one test case that
use generate_series() to insert data in a distributed table but still does
not fail. Its so because the test case uses a subquery to fire the insert.
So a workaround to the failing query is:

INSERT INTO testtbl SELECT generate_series(1,10000), 'foo';

Thanks,
Pavan
-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [Postgres-xc-developers] SRF not working ?

[Pavan D. <pav...@gm...>]

On Fri, Jul 5, 2013 at 6:26 AM, 鈴木 幸市 <ko...@in...> wrote:

> It is now in the bug tracker, ID is 3614635.   I'm afraid it's hard to
> include this improvement in 1.1.0 but will be fixed in the following
> releases.   I understand this has high priority.
>

Thank you for adding it to the tracker.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [Postgres-xc-developers] SRF not working ?

[Ashutosh B. <ash...@en...>]

On Thu, Jul 4, 2013 at 6:50 PM, Michael Paquier
<mic...@gm...>wrote:

> On Thu, Jul 4, 2013 at 7:07 PM, Pavan Deolasee <pav...@gm...>
> wrote:
> >
> > On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier <
> mic...@gm...>
> >> generate_series has never been fixed for hash tables as far as I recall.
> > Hmm.. that could well be the case. I am immensely surprised and
> disappointed
> > if that's true though. IMHO any PostgreSQL user will most likely fire
> that
> > statement soon after creating a table to populate test data. It does not
> > sound nice if the very first statement errors out.
> +1.
>
> > What stops us from supporting that, except of course lack of development
> time?
> That and the fact that such exceptions have never been considered a
> high priority, I suppose. generate_series is the particular case of an
> immutable function that cannot be FQS'ed for a non-replicated table. I
> might be wrong, but I think it worked correctly for roundrobin.
>
>
I don't agree that it's because of immutability. It has more to do with the
VALUES_RTE in INSERT statement. Any INSERT statement that is inserting more
than one value in the distributed table can not be FQSed. In case there are
more than one value being INSERTED through an INSERT statement, there are
two RTEs in the query, one for the relation where INSERT is happening, and
other for the values. So, I had implemented a simple rule in FQS
shippability - if there are more than one RTEs in INSERT statement, do not
FQS it. But I am unable to locate this rule now. Looks like while
implementing something else, the rule has disappeared. And, since we do not
have test for it, we didn't notice it.


> > Is it a hard problem to crack ?
> No I don't think so, but I've never taken the time to look at it.
>
> > I assume its the former because we just need to put it
> > through the slow path instead of FQS, no ?
> Yes, this is the case, it takes, or should take the slow path, and
> this even if the function is immutable. I recall that the output of
> EXPLAIN VERBOSE works correctly.
> --
> Michael
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company

Re: [Postgres-xc-developers] Query Planning bug ?

[Tomonari K. <kat...@po...>]

Hi Ashutosh, Abbas,

Sorry for slow response..
But still I can not run regression test.

 >>Ashutosh
 > see if copying query->rtable solves the issue. The changed code would 
look
 > like
 >
 > 3112         crte_context->crte_rtable =
 > list_concat(crte_context->crte_rtable,
 > 3113
 > list_copy(query->rtable));
 >
I've changed source as you said, and it seems resolving my problem(*).
(*) below query falt in endless loop.
------------------------------------------------------------------
EXECUTE DIRECT ON (data1) $$
SELECT
count(*)
FROM
(SELECT * FROM pg_locks l LEFT JOIN
(SELECT * FROM pg_stat_activity) s ON l.database = s.datid) a
$$
------------------------------------------------------------------

But I couldn't run regression test with this source too.
It stoped same test-case(xmlmap.sql).

 >>Abbas
 > Since you are getting a crash even without your patch there must be some
 > thing wrong in the deployment.
 > Can you try doing
 > ./configure --enable-debug --enable-cassert CFLAGS='-O0'
 > and then see whether its an assertion failure or not?
 > Also can you see which SQL statement is causing the crash in xmlmap.sql?
 >
I've tried the configure you said.
I didn't get any assertion failure, but regression test had
stoped in "test collate".


When Postgres-XC crashed with xmlmap.sql,
I found The SQL statement which is causing the crash.
----
DECLARE xc CURSOR WITH HOLD FOR SELECT * FROM testxmlschema.test1 ORDER 
BY 1, 2;
----

I think these are another problems.
Because I get same result with or without patched Postgres-XC.
so I want to discuss on another mails.


regards,
------------
NTT Software Corporation
Tomonari Katsumata




(2013/07/03 12:13), Abbas Butt wrote:
> Since you are getting a crash even without your patch there must be some
> thing wrong in the deployment.
> Can you try doing
> ./configure --enable-debug --enable-cassert CFLAGS='-O0'
> and then see whether its an assertion failure or not?
> Also can you see which SQL statement is causing the crash in xmlmap.sql?
>
> On Mon, Jul 1, 2013 at 4:51 PM, Tomonari Katsumata <
> t.k...@gm...> wrote:
>
>> Hi,
>>
>> I've tried regression test, but I could not
>> get right result.
>> Both patched and un-patched Postgres-XC get
>> same result, so I think my process is bad.
>>
>> I run a gtm, a gtm_proxy, a coordinator, a datanode
>> in one server(CentOS6.4 x86_64 on VMWare),
>> and hit "make installcheck".
>> The configure option is [--enable-debug CFLAGS=""].
>>
>> What is right way to run the regression test?
>>
>> output is below.
>> ---------------------------------------------------------
>> test tablespace               ... ok
>> test boolean                  ... ok
>> test char                     ... ok
>> test name                     ... ok
>> test varchar                  ... ok
>> test text                     ... ok
>> test int2                     ... ok
>> test int4                     ... ok
>> test int8                     ... ok
>> test oid                      ... ok
>> test float4                   ... ok
>> test float8                   ... ok
>> test bit                      ... ok
>> test numeric                  ... ok
>> test txid                     ... ok
>> test uuid                     ... ok
>> test enum                     ... FAILED
>> test money                    ... ok
>> test rangetypes               ... ok
>> test strings                  ... ok
>> test numerology               ... ok
>> test point                    ... ok
>> test lseg                     ... ok
>> test box                      ... ok
>> test path                     ... ok
>> test polygon                  ... ok
>> test circle                   ... ok
>> test date                     ... ok
>> test time                     ... ok
>> test timetz                   ... ok
>> test timestamp                ... ok
>> test timestamptz              ... ok
>> test interval                 ... ok
>> test abstime                  ... ok
>> test reltime                  ... ok
>> test tinterval                ... ok
>> test inet                     ... ok
>> test macaddr                  ... ok
>> test tstypes                  ... ok
>> test comments                 ... ok
>> test geometry                 ... ok
>> test horology                 ... ok
>> test regex                    ... ok
>> test oidjoins                 ... ok
>> test type_sanity              ... ok
>> test opr_sanity               ... ok
>> test insert                   ... ok
>> test create_function_1        ... ok
>> test create_type              ... ok
>> test create_table             ... ok
>> test create_function_2        ... ok
>> test create_function_3        ... ok
>> test copy                     ... ok
>> test copyselect               ... ok
>> test create_misc              ... ok
>> test create_operator          ... ok
>> test create_index             ... FAILED
>> test create_view              ... ok
>> test create_aggregate         ... ok
>> test create_cast              ... ok
>> test constraints              ... FAILED
>> test triggers                 ... ok
>> test inherit                  ... FAILED
>> test create_table_like        ... ok
>> test typed_table              ... ok
>> test vacuum                   ... ok
>> test drop_if_exists           ... ok
>> test sanity_check             ... ok
>> test errors                   ... ok
>> test select                   ... ok
>> test select_into              ... ok
>> test select_distinct          ... ok
>> test select_distinct_on       ... ok
>> test select_implicit          ... ok
>> test select_having            ... ok
>> test subselect                ... ok
>> test union                    ... ok
>> test case                     ... ok
>> test join                     ... FAILED
>> test aggregates               ... FAILED
>> test transactions             ... ok
>> test random                   ... ok
>> test portals                  ... ok
>> test arrays                   ... FAILED
>> test btree_index              ... ok
>> test hash_index               ... ok
>> test update                   ... ok
>> test delete                   ... ok
>> test namespace                ... ok
>> test prepared_xacts           ... ok
>> test privileges               ... FAILED
>> test security_label           ... ok
>> test collate                  ... FAILED
>> test misc                     ... ok
>> test rules                    ... ok
>> test select_views             ... ok
>> test portals_p2               ... ok
>> test foreign_key              ... ok
>> test cluster                  ... ok
>> test dependency               ... ok
>> test guc                      ... ok
>> test bitmapops                ... ok
>> test combocid                 ... ok
>> test tsearch                  ... ok
>> test tsdicts                  ... ok
>> test foreign_data             ... ok
>> test window                   ... ok
>> test xmlmap                   ... FAILED (test process exited with exit
>> code 2)
>> test functional_deps          ... FAILED (test process exited with exit
>> code 2)
>> test advisory_lock            ... FAILED (test process exited with exit
>> code 2)
>> test json                     ... FAILED (test process exited with exit
>> code 2)
>> test plancache                ... FAILED (test process exited with exit
>> code 2)
>> test limit                    ... FAILED (test process exited with exit
>> code 2)
>> test plpgsql                  ... FAILED (test process exited with exit
>> code 2)
>> test copy2                    ... FAILED (test process exited with exit
>> code 2)
>> test temp                     ... FAILED (test process exited with exit
>> code 2)
>> test domain                   ... FAILED (test process exited with exit
>> code 2)
>> test rangefuncs               ... FAILED (test process exited with exit
>> code 2)
>> test prepare                  ... FAILED (test process exited with exit
>> code 2)
>> test without_oid              ... FAILED (test process exited with exit
>> code 2)
>> test conversion               ... FAILED (test process exited with exit
>> code 2)
>> test truncate                 ... FAILED (test process exited with exit
>> code 2)
>> test alter_table              ... FAILED (test process exited with exit
>> code 2)
>> test sequence                 ... FAILED (test process exited with exit
>> code 2)
>> test polymorphism             ... FAILED (test process exited with exit
>> code 2)
>> test rowtypes                 ... FAILED (test process exited with exit
>> code 2)
>> test returning                ... FAILED (test process exited with exit
>> code 2)
>> test largeobject              ... FAILED (test process exited with exit
>> code 2)
>> test with                     ... FAILED (test process exited with exit
>> code 2)
>> test xml                      ... FAILED (test process exited with exit
>> code 2)
>> test stats                    ... FAILED (test process exited with exit
>> code 2)
>> test xc_create_function       ... FAILED (test process exited with exit
>> code 2)
>> test xc_groupby               ... FAILED (test process exited with exit
>> code 2)
>> test xc_distkey               ... FAILED (test process exited with exit
>> code 2)
>> test xc_having                ... FAILED (test process exited with exit
>> code 2)
>> test xc_temp                  ... FAILED (test process exited with exit
>> code 2)
>> test xc_remote                ... FAILED (test process exited with exit
>> code 2)
>> test xc_node                  ... FAILED (test process exited with exit
>> code 2)
>> test xc_FQS                   ... FAILED (test process exited with exit
>> code 2)
>> test xc_FQS_join              ... FAILED (test process exited with exit
>> code 2)
>> test xc_misc                  ... FAILED (test process exited with exit
>> code 2)
>> test xc_triggers              ... FAILED (test process exited with exit
>> code 2)
>> test xc_trigship              ... FAILED (test process exited with exit
>> code 2)
>> test xc_constraints           ... FAILED (test process exited with exit
>> code 2)
>> test xc_copy                  ... FAILED (test process exited with exit
>> code 2)
>> test xc_alter_table           ... FAILED (test process exited with exit
>> code 2)
>> test xc_sequence              ... FAILED (test process exited with exit
>> code 2)
>> test xc_prepared_xacts        ... FAILED (test process exited with exit
>> code 2)
>> test xc_notrans_block         ... FAILED (test process exited with exit
>> code 2)
>> test xc_limit                 ... FAILED (test process exited with exit
>> code 2)
>> test xc_sort                  ... FAILED (test process exited with exit
>> code 2)
>> test xc_returning             ... FAILED (test process exited with exit
>> code 2)
>> test xc_params                ... FAILED (test process exited with exit
>> code 2)
>> =========================
>>   55 of 153 tests failed.
>> =========================
>>
>>
>> 2013/7/1 Tomonari Katsumata <kat...@po...>
>>
>>> Hi Ashutosh,
>>>
>>> OK, I'll try regression test.
>>> Please wait for the result.
>>>
>>> regards,
>>> ------------
>>> NTT Software Corporation
>>> Tomonari Katsumata
>>>
>>> (2013/07/01 17:06), Ashutosh Bapat wrote:
>>>> Hi Tomonori,
>>>>
>>>>
>>>>
>>>> On Mon, Jul 1, 2013 at 1:33 PM, Tomonari Katsumata <
>>>> kat...@po...> wrote:
>>>>
>>>>> Hi Ashutosh and all,
>>>>>
>>>>> Sorry for late response.
>>>>> I made a patch for resolving the problem I mentioned before.
>>>>>
>>>>> I thought the reason of this problem is parsing query twice.
>>>>> because of this, the rtable is made from same Lists and become
>>>>> cycliced List.
>>>>> I fixed this problem with making former List empty.
>>>>>
>>>>> I'm not sure this fix leads any anothre problems but
>>>>> the problem query I mentioned before works fine.
>>>>>
>>>>> This patch is against for
>>> "**a074cac9b6b507e6d4b58c5004673f**6cc65fcde1".
>>>>>
>>>> You can check the robustness of patch by running regression. Please let
>>> me
>>>> know what you see.
>>>>
>>>>
>>>>> regards,
>>>>> ------------------
>>>>> NTT Software Corporation
>>>>> Tomonari Katsumata
>>>>>
>>>>>
>>>>> (2013/06/17 18:53), Ashutosh Bapat wrote:
>>>>>
>>>>>> Hi Tomonari,
>>>>>> In which function have you taken this debug info? What is list1 and
>>> list2?
>>>>>>
>>>>>> On Mon, Jun 17, 2013 at 10:13 AM, Tomonari Katsumata <
>>>>>> kat...@po....**jp <kat...@po...
>>>>>> wrote:
>>>>>>
>>>>>>    Hi Ashtosh,
>>>>>>> Sorry for slow response.
>>>>>>>
>>>>>>> I've watched the each lists at list_concat function.
>>>>>>>
>>>>>>> This function is called several times, but the lists before
>>>>>>> last infinitely roop are like below.
>>>>>>>
>>>>>>> [list1]
>>>>>>> (gdb) p *list1->head
>>>>>>> $18 = {data = {ptr_value = 0x17030e8, int_value = 24129768,
>>>>>>>         oid_value = 24129768}, next = 0x170d418}
>>>>>>> (gdb) p *list1->head->next
>>>>>>> $19 = {data = {ptr_value = 0x17033d0, int_value = 24130512,
>>>>>>>         oid_value = 24130512}, next = 0x170fd40}
>>>>>>> (gdb) p *list1->head->next->next
>>>>>>> $20 = {data = {ptr_value = 0x170ae58, int_value = 24161880,
>>>>>>>         oid_value = 24161880}, next = 0x171e6c8}
>>>>>>> (gdb) p *list1->head->next->next->next
>>>>>>> $21 = {data = {ptr_value = 0x1702ca8, int_value = 24128680,
>>>>>>>         oid_value = 24128680}, next = 0x171ed28}
>>>>>>> (gdb) p *list1->head->next->next->**next->next
>>>>>>> $22 = {data = {ptr_value = 0x170af68, int_value = 24162152,
>>>>>>>         oid_value = 24162152}, next = 0x171f3a0}
>>>>>>> (gdb) p *list1->head->next->next->**next->next->next
>>>>>>> $23 = {data = {ptr_value = 0x170b0a8, int_value = 24162472,
>>>>>>>         oid_value = 24162472}, next = 0x170b7c0}
>>>>>>> (gdb) p *list1->head->next->next->**next->next->next->next
>>>>>>> $24 = {data = {ptr_value = 0x17035f0, int_value = 24131056,
>>>>>>>         oid_value = 24131056}, next = 0x1720998}
>>>>>>> ---- from ---
>>>>>>> (gdb) p *list1->head->next->next->**next->next->next->next->next
>>>>>>> $25 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>>>>>>>         oid_value = 24250808}, next = 0x1721190}
>>>>>>> (gdb) p
>>> *list1->head->next->next->**next->next->next->next->next->**next
>>>>>>> $26 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>>>>>>>         oid_value = 24252848}, next = 0x1721988}
>>>>>>> (gdb) p *list1->head->next->next->**next->next->next->next->next->**
>>>>>>> next->next
>>>>>>> $27 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>>>>>>>         oid_value = 24254888}, next = 0x1722018}
>>>>>>> (gdb) p
>>>>>>> *list1->head->next->next->**next->next->next->next->next->**
>>>>>>> next->next->next
>>>>>>> $28 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>>>>>>>         oid_value = 24256568}, next = 0x1722820}
>>>>>>> (gdb) p
>>>>>>>
>>>>>>> *list1->head->next->next->**next->next->next->next->next->**
>>>>>>> next->next->next->next
>>>>>>> $29 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>>>>>>>         oid_value = 24258624}, next = 0x0}
>>>>>>> ---- to ----
>>>>>>>
>>>>>>> [list2]
>>>>>>> (gdb) p *list2->head
>>>>>>> $31 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>>>>>>>         oid_value = 24250808}, next = 0x1721190}
>>>>>>> (gdb) p *list2->head->next
>>>>>>> $32 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>>>>>>>         oid_value = 24252848}, next = 0x1721988}
>>>>>>> (gdb) p *list2->head->next->next
>>>>>>> $33 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>>>>>>>         oid_value = 24254888}, next = 0x1722018}
>>>>>>> (gdb) p *list2->head->next->next->next
>>>>>>> $34 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>>>>>>>         oid_value = 24256568}, next = 0x1722820}
>>>>>>> (gdb) p *list2->head->next->next->**next->next
>>>>>>> $35 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>>>>>>>         oid_value = 24258624}, next = 0x0}
>>>>>>> ----
>>>>>>>
>>>>>>> list1's last five elements are same with list2's all elements.
>>>>>>> (in above example, between "from" and "to" in list1 equal all of
>>> list2)
>>>>>>> This is cause of infinitely roop, but I can not
>>>>>>> watch deeper.
>>>>>>> Because some values from gdb are optimized and un-displayed.
>>>>>>> I tried compile with CFLAGS=O0, but I can't.
>>>>>>>
>>>>>>> What can I do more ?
>>>>>>>
>>>>>>> regards,
>>>>>>> ------------------
>>>>>>> NTT Software Corporation
>>>>>>> Tomonari Katsumata
>>>>>>>
>>>>>>> (2013/06/12 21:04), Ashutosh Bapat wrote:
>>>>>>>     > Hi Tomonari,
>>>>>>>     > Can you please check the list's sanity before calling
>>>>>>> pgxc_collect_RTE()
>>>>>>>     > and at every point in the minions of this function. My primary
>>>>>>> suspect
>>>>>>> is
>>>>>>>     > the line pgxcplan.c:3094. We should copy the list before
>>>>>>> concatenating it.
>>>>>>>     >
>>>>>>>     >
>>>>>>>     > On Wed, Jun 12, 2013 at 2:26 PM, Tomonari Katsumata <
>>>>>>>     > kat...@po....**jp<
>>> kat...@po...>>
>>>>>>> wrote:
>>>>>>>     >
>>>>>>>     >> Hi Ashutosh,
>>>>>>>     >>
>>>>>>>     >> Thank you for the response.
>>>>>>>     >>
>>>>>>>     >> (2013/06/12 14:43), Ashutosh Bapat wrote:
>>>>>>>     >>  >> Hi,
>>>>>>>     >>  >> >
>>>>>>>     >>  >> > I've investigated this problem(BUG:3614369).
>>>>>>>     >>  >> >
>>>>>>>     >>  >> > I caught the cause of it, but I can not
>>>>>>>     >>  >> > find where to fix.
>>>>>>>     >>  >> >
>>>>>>>     >>  >> > The problem occurs when "pgxc_collect_RTE_walker" is
>>> called
>>>>>>>     >> infinitely.
>>>>>>>     >>  >> > It seems that rtable(List of RangeTable) become cyclic
>>> List.
>>>>>>>     >>  >> > I'm not sure where the List is made.
>>>>>>>     >>  >> >
>>>>>>>     >>  >> >
>>>>>>>     >>  > I guess, we are talking about EXECUTE DIRECT statement that
>>> you
>>>>>>> have
>>>>>>>     >>  > mentioned earlier.
>>>>>>>     >>
>>>>>>>     >> Yes, that's right.
>>>>>>>     >> I'm talking about EXECUTE DIRECT statement like below.
>>>>>>>     >>   ---
>>>>>>>     >>   EXECUTE DIRECT ON (data1) $$
>>>>>>>     >>   SELECT
>>>>>>>     >>   count(*)
>>>>>>>     >>   FROM
>>>>>>>     >>   (SELECT * FROM pg_locks l LEFT JOIN
>>>>>>>     >>   (SELECT * FROM pg_stat_activity) s ON l.database = s.datid) a
>>>>>>>     >>   $$
>>>>>>>     >>   ---
>>>>>>>     >>
>>>>>>>     >>  > The function pgxc_collect_RTE_walker() is a recursive
>>>>>>>     >>  > function. The condition to end the recursion is if the given
>>>>>>> node is
>>>>>>>     >> NULL.
>>>>>>>     >>  > We have to look at if that condition is met and if not why.
>>>>>>>     >>  >
>>>>>>>     >> I investigated it deeper, and I noticed that
>>>>>>>     >> the infinitely loop happens at the function
>>> "range_table_walker()".
>>>>>>>     >>
>>>>>>>     >> Please see below trace.
>>>>>>>     >> ===========================
>>>>>>>     >> Breakpoint 1, range_table_walker (rtable=0x15e7968,
>>> walker=0x612c70
>>>>>>>     >> <pgxc_collect_RTE_walker>, context=0x7fffd2de31c0,
>>>>>>>     >>      flags=0) at nodeFuncs.c:1908
>>>>>>>     >> 1908    in nodeFuncs.c
>>>>>>>     >>
>>>>>>>     >> (gdb) p *rtable
>>>>>>>     >> $10 = {type = T_List, length = 5, head = 0x15e7998, tail =
>>>>>>> 0x15e9820}
>>>>>>>     >> (gdb) p *rtable->head
>>>>>>>     >> $11 = {data = {ptr_value = 0x15e79b8, int_value = 22968760,
>>>>>>> oid_value =
>>>>>>>     >> 22968760}, next = 0x15e8190}
>>>>>>>     >> (gdb) p *rtable->head->next
>>>>>>>     >> $12 = {data = {ptr_value = 0x15e81b0, int_value = 22970800,
>>>>>>> oid_value =
>>>>>>>     >> 22970800}, next = 0x15e8988}
>>>>>>>     >> (gdb) p *rtable->head->next->next
>>>>>>>     >> $13 = {data = {ptr_value = 0x15e89a8, int_value = 22972840,
>>>>>>> oid_value =
>>>>>>>     >> 22972840}, next = 0x15e9018}
>>>>>>>     >> (gdb) p *rtable->head->next->next->**next
>>>>>>>     >> $14 = {data = {ptr_value = 0x15e9038, int_value = 22974520,
>>>>>>> oid_value =
>>>>>>>     >> 22974520}, next = 0x15e9820}
>>>>>>>     >> (gdb) p *rtable->head->next->next->**next->next
>>>>>>>     >> $15 = {data = {ptr_value = 0x15e9840, int_value = 22976576,
>>>>>>> oid_value =
>>>>>>>     >> 22976576}, next = 0x15e7998}
>>>>>>>     >> ===========================
>>>>>>>     >>
>>>>>>>     >> The line which starts with "$15" has 0x15e7998 as its next
>>> data.
>>>>>>>     >> But it is the head pointer(see the line which starts with $10).
>>>>>>>     >>
>>>>>>>     >> And in range_table_walker(), the function is called
>>> recursively.
>>>>>>>     >> --------
>>>>>>>     >> ...
>>>>>>>     >>          if (!(flags & QTW_IGNORE_RANGE_TABLE))
>>>>>>>     >>          {
>>>>>>>     >>                  if (range_table_walker(query->**rtable,
>>> walker,
>>>>>>> context,
>>>>>>>     >> flags))
>>>>>>>     >>                          return true;
>>>>>>>     >>          }
>>>>>>>     >> ...
>>>>>>>     >> --------
>>>>>>>     >>
>>>>>>>     >> We should make rtable right or deal with "flags" properly.
>>>>>>>     >> But I can't find where to do it...
>>>>>>>     >>
>>>>>>>     >> What do you think ?
>>>>>>>     >>
>>>>>>>     >> regards,
>>>>>>>     >> ---------
>>>>>>>     >> NTT Software Corporation
>>>>>>>     >> Tomonari Katsumata
>>>>>>>     >>
>>>>>>>     >>
>>>>>>>     >>
>>>>>>>     >>
>>>>>>>     >>
>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ------------------
>>>>>>>     >> This SF.net email is sponsored by Windows:
>>>>>>>     >>
>>>>>>>     >> Build for Windows Store.
>>>>>>>     >>
>>>>>>>     >> http://p.sf.net/sfu/windows-**dev2dev<
>>> http://p.sf.net/sfu/windows-dev2dev>
>>>>>>>     >> ______________________________**_________________
>>>>>>>     >> Postgres-xc-developers mailing list
>>>>>>>     >> Postgres-xc-developers@lists.**sourceforge.net<
>>> Pos...@li...>
>>>>>>>     >> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**
>>>>>>> developers<
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
>>>>>>>     >>
>>>>>>>     >
>>>>>>>     >
>>>>>>>     >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ------------------
>>>>>>> This SF.net email is sponsored by Windows:
>>>>>>>
>>>>>>> Build for Windows Store.
>>>>>>>
>>>>>>> http://p.sf.net/sfu/windows-**dev2dev<
>>> http://p.sf.net/sfu/windows-dev2dev>
>>>>>>> ______________________________**_________________
>>>>>>> Postgres-xc-developers mailing list
>>>>>>> Postgres-xc-developers@lists.**sourceforge.net<
>>> Pos...@li...>
>>> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**developers<
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
>>>>>>>
>>>>>
>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Windows:
>>>>>
>>>>> Build for Windows Store.
>>>>>
>>>>> http://p.sf.net/sfu/windows-dev2dev
>>>>> _______________________________________________
>>>>> Postgres-xc-developers mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>> _______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Re: [Postgres-xc-developers] SRF not working ?

[鈴木 幸市 <ko...@in...>]

It is now in the bug tracker, ID is 3614635.   I'm afraid it's hard to include this improvement in 1.1.0 but will be fixed in the following releases.   I understand this has high priority.

Regards;
---
Koichi Suzuki



On 2013/07/04, at 22:20, Michael Paquier <mic...@gm...> wrote:

> On Thu, Jul 4, 2013 at 7:07 PM, Pavan Deolasee <pav...@gm...> wrote:
>> 
>> On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier <mic...@gm...>
>>> generate_series has never been fixed for hash tables as far as I recall.
>> Hmm.. that could well be the case. I am immensely surprised and disappointed
>> if that's true though. IMHO any PostgreSQL user will most likely fire that
>> statement soon after creating a table to populate test data. It does not
>> sound nice if the very first statement errors out.
> +1.
> 
>> What stops us from supporting that, except of course lack of development time?
> That and the fact that such exceptions have never been considered a
> high priority, I suppose. generate_series is the particular case of an
> immutable function that cannot be FQS'ed for a non-replicated table. I
> might be wrong, but I think it worked correctly for roundrobin.
> 
>> Is it a hard problem to crack ?
> No I don't think so, but I've never taken the time to look at it.
> 
>> I assume its the former because we just need to put it
>> through the slow path instead of FQS, no ?
> Yes, this is the case, it takes, or should take the slow path, and
> this even if the function is immutable. I recall that the output of
> EXPLAIN VERBOSE works correctly.
> --
> Michael
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 

Re: [Postgres-xc-developers] SRF not working ?

[Michael P. <mic...@gm...>]

On Thu, Jul 4, 2013 at 7:07 PM, Pavan Deolasee <pav...@gm...> wrote:
>
> On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier <mic...@gm...>
>> generate_series has never been fixed for hash tables as far as I recall.
> Hmm.. that could well be the case. I am immensely surprised and disappointed
> if that's true though. IMHO any PostgreSQL user will most likely fire that
> statement soon after creating a table to populate test data. It does not
> sound nice if the very first statement errors out.
+1.

> What stops us from supporting that, except of course lack of development time?
That and the fact that such exceptions have never been considered a
high priority, I suppose. generate_series is the particular case of an
immutable function that cannot be FQS'ed for a non-replicated table. I
might be wrong, but I think it worked correctly for roundrobin.

> Is it a hard problem to crack ?
No I don't think so, but I've never taken the time to look at it.

> I assume its the former because we just need to put it
> through the slow path instead of FQS, no ?
Yes, this is the case, it takes, or should take the slow path, and
this even if the function is immutable. I recall that the output of
EXPLAIN VERBOSE works correctly.
--
Michael

Re: [Postgres-xc-developers] SRF not working ?

[Nikhil S. <ni...@st...>]

> Hmm.. that could well be the case. I am immensely surprised and
> disappointed if that's true though. IMHO any PostgreSQL user will most
> likely fire that statement soon after creating a table to populate test
> data. It does not sound nice if the very first statement errors out. What
> stops us from supporting that, except of course lack of development time ?
> Is it a hard problem to crack ? I assume its the former because we just
> need to put it through the slow path instead of FQS, no ?
>
> +1

I would have assumed that INSERTs would have been special cased to
precisely allow the coordinator to decide to which datanodes to send the
INSERT to.

Regards,
Nikhils


> Thanks,
> Pavan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
StormDB - http://www.stormdb.com
The Database Cloud

Re: [Postgres-xc-developers] SRF not working ?

[Pavan D. <pav...@gm...>]

On Thu, Jul 4, 2013 at 3:21 PM, Michael Paquier
<mic...@gm...>wrote:

>
> generate_series has has never been fixed for hash tables as far as I
> recall.


Hmm.. that could well be the case. I am immensely surprised and
disappointed if that's true though. IMHO any PostgreSQL user will most
likely fire that statement soon after creating a table to populate test
data. It does not sound nice if the very first statement errors out. What
stops us from supporting that, except of course lack of development time ?
Is it a hard problem to crack ? I assume its the former because we just
need to put it through the slow path instead of FQS, no ?

Thanks,
Pavan

Re: [Postgres-xc-developers] SRF not working ?

[Michael P. <mic...@gm...>]

On Thu, Jul 4, 2013 at 5:34 PM, Pavan Deolasee <pav...@gm...> wrote:
> Hello All,
>
> I tried to use generate_series() function to load a bunch of test data in a
> table. It fails with the following error:
>
> psql (PGXC 1.1devel, based on PG 9.2beta2)
> Type "help" for help.
>
> postgres=# CREATE TABLE testtbl(a int, b char(10));
> CREATE TABLE
> postgres=# \d+ testtbl
>                            Table "public.testtbl"
>  Column |     Type      | Modifiers | Storage  | Stats target | Description
> --------+---------------+-----------+----------+--------------+-------------
>  a      | integer       |           | plain    |              |
>  b      | character(10) |           | extended |              |
> Has OIDs: no
> Distribute By: HASH(a)
> Location Nodes: ALL DATANODES
>
> postgres=# INSERT INTO testtbl VALUES (generate_series(1,10000), 'foo');
> ERROR:  set-valued function called in context that cannot accept a set
>
> I thought we had fixed this issue long back, no ? I also tried to search the
> list and it seems it used to work at some point. Am I doing something wrong
> ? I'm using the master branch from the repository.
generate_series has has never been fixed for hash tables as far as I recall.
--
Michael

Re: [Postgres-xc-developers] SRF not working ?

[Pavan D. <pav...@gm...>]

On Thu, Jul 4, 2013 at 2:10 PM, 鈴木 幸市 <ko...@in...> wrote:

> We've cleaned up some function I/F and it may influenced the case.
>
> Any more info?
>

It seems we are trying to FQS this query, which is clearly wrong. The
INSERTs must go through the coordinator so that each row can be inserted in
the relevant datanode. If I turn FQS off, then the INSERT works fine.

postgres=# set enable_fast_query_shipping TO on;
SET
postgres=# EXPLAIN INSERT INTO testtbl VALUES (generate_series(1,10000),
'foo');
                                 QUERY PLAN
----------------------------------------------------------------------------
 Data Node Scan on "__REMOTE_FQS_QUERY__"  (cost=0.00..0.00 rows=0 width=0)
   Node expr: generate_series(1, 10000)
(2 rows)

postgres=# set enable_fast_query_shipping TO off;
SET
postgres=# EXPLAIN INSERT INTO testtbl VALUES (generate_series(1,10000),
'foo');
                     QUERY PLAN
-----------------------------------------------------
 Insert on testtbl  (cost=0.00..0.01 rows=1 width=0)
   Node/s: d1, d2
   Node expr: a
   ->  Result  (cost=0.00..0.01 rows=1 width=0)
(4 rows)

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [Postgres-xc-developers] SRF not working ?

[鈴木 幸市 <ko...@in...>]

We've cleaned up some function I/F and it may influenced the case.

Any more info?
---
Koichi Suzuki



On 2013/07/04, at 17:34, Pavan Deolasee <pav...@gm...> wrote:

> Hello All,
> 
> I tried to use generate_series() function to load a bunch of test data in a table. It fails with the following error:
> 
> psql (PGXC 1.1devel, based on PG 9.2beta2)
> Type "help" for help.
> 
> postgres=# CREATE TABLE testtbl(a int, b char(10));
> CREATE TABLE
> postgres=# \d+ testtbl
>                            Table "public.testtbl"
>  Column |     Type      | Modifiers | Storage  | Stats target | Description 
> --------+---------------+-----------+----------+--------------+-------------
>  a      | integer       |           | plain    |              | 
>  b      | character(10) |           | extended |              | 
> Has OIDs: no
> Distribute By: HASH(a)
> Location Nodes: ALL DATANODES
> 
> postgres=# INSERT INTO testtbl VALUES (generate_series(1,10000), 'foo');
> ERROR:  set-valued function called in context that cannot accept a set
> 
> I thought we had fixed this issue long back, no ? I also tried to search the list and it seems it used to work at some point. Am I doing something wrong ? I'm using the master branch from the repository.
> 
> Thanks,
> Pavan
> -- 
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

[Postgres-xc-developers] SRF not working ?

[Pavan D. <pav...@gm...>]

Hello All,

I tried to use generate_series() function to load a bunch of test data in a
table. It fails with the following error:

psql (PGXC 1.1devel, based on PG 9.2beta2)
Type "help" for help.

postgres=# CREATE TABLE testtbl(a int, b char(10));
CREATE TABLE
postgres=# \d+ testtbl
                           Table "public.testtbl"
 Column |     Type      | Modifiers | Storage  | Stats target | Description
--------+---------------+-----------+----------+--------------+-------------
 a      | integer       |           | plain    |              |
 b      | character(10) |           | extended |              |
Has OIDs: no
Distribute By: HASH(a)
Location Nodes: ALL DATANODES

postgres=# INSERT INTO testtbl VALUES (generate_series(1,10000), 'foo');
ERROR:  set-valued function called in context that cannot accept a set

I thought we had fixed this issue long back, no ? I also tried to search
the list and it seems it used to work at some point. Am I doing something
wrong ? I'm using the master branch from the repository.

Thanks,
Pavan
-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [Postgres-xc-developers] Query Planning bug ?

[Abbas B. <abb...@en...>]

Since you are getting a crash even without your patch there must be some
thing wrong in the deployment.
Can you try doing
./configure --enable-debug --enable-cassert CFLAGS='-O0'
and then see whether its an assertion failure or not?
Also can you see which SQL statement is causing the crash in xmlmap.sql?

On Mon, Jul 1, 2013 at 4:51 PM, Tomonari Katsumata <
t.k...@gm...> wrote:

> Hi,
>
> I've tried regression test, but I could not
> get right result.
> Both patched and un-patched Postgres-XC get
> same result, so I think my process is bad.
>
> I run a gtm, a gtm_proxy, a coordinator, a datanode
> in one server(CentOS6.4 x86_64 on VMWare),
> and hit "make installcheck".
> The configure option is [--enable-debug CFLAGS=""].
>
> What is right way to run the regression test?
>
> output is below.
> ---------------------------------------------------------
> test tablespace               ... ok
> test boolean                  ... ok
> test char                     ... ok
> test name                     ... ok
> test varchar                  ... ok
> test text                     ... ok
> test int2                     ... ok
> test int4                     ... ok
> test int8                     ... ok
> test oid                      ... ok
> test float4                   ... ok
> test float8                   ... ok
> test bit                      ... ok
> test numeric                  ... ok
> test txid                     ... ok
> test uuid                     ... ok
> test enum                     ... FAILED
> test money                    ... ok
> test rangetypes               ... ok
> test strings                  ... ok
> test numerology               ... ok
> test point                    ... ok
> test lseg                     ... ok
> test box                      ... ok
> test path                     ... ok
> test polygon                  ... ok
> test circle                   ... ok
> test date                     ... ok
> test time                     ... ok
> test timetz                   ... ok
> test timestamp                ... ok
> test timestamptz              ... ok
> test interval                 ... ok
> test abstime                  ... ok
> test reltime                  ... ok
> test tinterval                ... ok
> test inet                     ... ok
> test macaddr                  ... ok
> test tstypes                  ... ok
> test comments                 ... ok
> test geometry                 ... ok
> test horology                 ... ok
> test regex                    ... ok
> test oidjoins                 ... ok
> test type_sanity              ... ok
> test opr_sanity               ... ok
> test insert                   ... ok
> test create_function_1        ... ok
> test create_type              ... ok
> test create_table             ... ok
> test create_function_2        ... ok
> test create_function_3        ... ok
> test copy                     ... ok
> test copyselect               ... ok
> test create_misc              ... ok
> test create_operator          ... ok
> test create_index             ... FAILED
> test create_view              ... ok
> test create_aggregate         ... ok
> test create_cast              ... ok
> test constraints              ... FAILED
> test triggers                 ... ok
> test inherit                  ... FAILED
> test create_table_like        ... ok
> test typed_table              ... ok
> test vacuum                   ... ok
> test drop_if_exists           ... ok
> test sanity_check             ... ok
> test errors                   ... ok
> test select                   ... ok
> test select_into              ... ok
> test select_distinct          ... ok
> test select_distinct_on       ... ok
> test select_implicit          ... ok
> test select_having            ... ok
> test subselect                ... ok
> test union                    ... ok
> test case                     ... ok
> test join                     ... FAILED
> test aggregates               ... FAILED
> test transactions             ... ok
> test random                   ... ok
> test portals                  ... ok
> test arrays                   ... FAILED
> test btree_index              ... ok
> test hash_index               ... ok
> test update                   ... ok
> test delete                   ... ok
> test namespace                ... ok
> test prepared_xacts           ... ok
> test privileges               ... FAILED
> test security_label           ... ok
> test collate                  ... FAILED
> test misc                     ... ok
> test rules                    ... ok
> test select_views             ... ok
> test portals_p2               ... ok
> test foreign_key              ... ok
> test cluster                  ... ok
> test dependency               ... ok
> test guc                      ... ok
> test bitmapops                ... ok
> test combocid                 ... ok
> test tsearch                  ... ok
> test tsdicts                  ... ok
> test foreign_data             ... ok
> test window                   ... ok
> test xmlmap                   ... FAILED (test process exited with exit
> code 2)
> test functional_deps          ... FAILED (test process exited with exit
> code 2)
> test advisory_lock            ... FAILED (test process exited with exit
> code 2)
> test json                     ... FAILED (test process exited with exit
> code 2)
> test plancache                ... FAILED (test process exited with exit
> code 2)
> test limit                    ... FAILED (test process exited with exit
> code 2)
> test plpgsql                  ... FAILED (test process exited with exit
> code 2)
> test copy2                    ... FAILED (test process exited with exit
> code 2)
> test temp                     ... FAILED (test process exited with exit
> code 2)
> test domain                   ... FAILED (test process exited with exit
> code 2)
> test rangefuncs               ... FAILED (test process exited with exit
> code 2)
> test prepare                  ... FAILED (test process exited with exit
> code 2)
> test without_oid              ... FAILED (test process exited with exit
> code 2)
> test conversion               ... FAILED (test process exited with exit
> code 2)
> test truncate                 ... FAILED (test process exited with exit
> code 2)
> test alter_table              ... FAILED (test process exited with exit
> code 2)
> test sequence                 ... FAILED (test process exited with exit
> code 2)
> test polymorphism             ... FAILED (test process exited with exit
> code 2)
> test rowtypes                 ... FAILED (test process exited with exit
> code 2)
> test returning                ... FAILED (test process exited with exit
> code 2)
> test largeobject              ... FAILED (test process exited with exit
> code 2)
> test with                     ... FAILED (test process exited with exit
> code 2)
> test xml                      ... FAILED (test process exited with exit
> code 2)
> test stats                    ... FAILED (test process exited with exit
> code 2)
> test xc_create_function       ... FAILED (test process exited with exit
> code 2)
> test xc_groupby               ... FAILED (test process exited with exit
> code 2)
> test xc_distkey               ... FAILED (test process exited with exit
> code 2)
> test xc_having                ... FAILED (test process exited with exit
> code 2)
> test xc_temp                  ... FAILED (test process exited with exit
> code 2)
> test xc_remote                ... FAILED (test process exited with exit
> code 2)
> test xc_node                  ... FAILED (test process exited with exit
> code 2)
> test xc_FQS                   ... FAILED (test process exited with exit
> code 2)
> test xc_FQS_join              ... FAILED (test process exited with exit
> code 2)
> test xc_misc                  ... FAILED (test process exited with exit
> code 2)
> test xc_triggers              ... FAILED (test process exited with exit
> code 2)
> test xc_trigship              ... FAILED (test process exited with exit
> code 2)
> test xc_constraints           ... FAILED (test process exited with exit
> code 2)
> test xc_copy                  ... FAILED (test process exited with exit
> code 2)
> test xc_alter_table           ... FAILED (test process exited with exit
> code 2)
> test xc_sequence              ... FAILED (test process exited with exit
> code 2)
> test xc_prepared_xacts        ... FAILED (test process exited with exit
> code 2)
> test xc_notrans_block         ... FAILED (test process exited with exit
> code 2)
> test xc_limit                 ... FAILED (test process exited with exit
> code 2)
> test xc_sort                  ... FAILED (test process exited with exit
> code 2)
> test xc_returning             ... FAILED (test process exited with exit
> code 2)
> test xc_params                ... FAILED (test process exited with exit
> code 2)
> =========================
>  55 of 153 tests failed.
> =========================
>
>
> 2013/7/1 Tomonari Katsumata <kat...@po...>
>
>> Hi Ashutosh,
>>
>> OK, I'll try regression test.
>> Please wait for the result.
>>
>> regards,
>> ------------
>> NTT Software Corporation
>> Tomonari Katsumata
>>
>> (2013/07/01 17:06), Ashutosh Bapat wrote:
>> > Hi Tomonori,
>> >
>> >
>> >
>> > On Mon, Jul 1, 2013 at 1:33 PM, Tomonari Katsumata <
>> > kat...@po...> wrote:
>> >
>> >> Hi Ashutosh and all,
>> >>
>> >> Sorry for late response.
>> >> I made a patch for resolving the problem I mentioned before.
>> >>
>> >> I thought the reason of this problem is parsing query twice.
>> >> because of this, the rtable is made from same Lists and become
>> >> cycliced List.
>> >> I fixed this problem with making former List empty.
>> >>
>> >> I'm not sure this fix leads any anothre problems but
>> >> the problem query I mentioned before works fine.
>> >>
>> >> This patch is against for
>> "**a074cac9b6b507e6d4b58c5004673f**6cc65fcde1".
>> >>
>> >>
>> > You can check the robustness of patch by running regression. Please let
>> me
>> > know what you see.
>> >
>> >
>> >> regards,
>> >> ------------------
>> >> NTT Software Corporation
>> >> Tomonari Katsumata
>> >>
>> >>
>> >> (2013/06/17 18:53), Ashutosh Bapat wrote:
>> >>
>> >>> Hi Tomonari,
>> >>> In which function have you taken this debug info? What is list1 and
>> list2?
>> >>>
>> >>>
>> >>> On Mon, Jun 17, 2013 at 10:13 AM, Tomonari Katsumata <
>> >>> kat...@po....**jp <kat...@po...
>> >>
>> >>> wrote:
>> >>>
>> >>>   Hi Ashtosh,
>> >>>> Sorry for slow response.
>> >>>>
>> >>>> I've watched the each lists at list_concat function.
>> >>>>
>> >>>> This function is called several times, but the lists before
>> >>>> last infinitely roop are like below.
>> >>>>
>> >>>> [list1]
>> >>>> (gdb) p *list1->head
>> >>>> $18 = {data = {ptr_value = 0x17030e8, int_value = 24129768,
>> >>>>        oid_value = 24129768}, next = 0x170d418}
>> >>>> (gdb) p *list1->head->next
>> >>>> $19 = {data = {ptr_value = 0x17033d0, int_value = 24130512,
>> >>>>        oid_value = 24130512}, next = 0x170fd40}
>> >>>> (gdb) p *list1->head->next->next
>> >>>> $20 = {data = {ptr_value = 0x170ae58, int_value = 24161880,
>> >>>>        oid_value = 24161880}, next = 0x171e6c8}
>> >>>> (gdb) p *list1->head->next->next->next
>> >>>> $21 = {data = {ptr_value = 0x1702ca8, int_value = 24128680,
>> >>>>        oid_value = 24128680}, next = 0x171ed28}
>> >>>> (gdb) p *list1->head->next->next->**next->next
>> >>>> $22 = {data = {ptr_value = 0x170af68, int_value = 24162152,
>> >>>>        oid_value = 24162152}, next = 0x171f3a0}
>> >>>> (gdb) p *list1->head->next->next->**next->next->next
>> >>>> $23 = {data = {ptr_value = 0x170b0a8, int_value = 24162472,
>> >>>>        oid_value = 24162472}, next = 0x170b7c0}
>> >>>> (gdb) p *list1->head->next->next->**next->next->next->next
>> >>>> $24 = {data = {ptr_value = 0x17035f0, int_value = 24131056,
>> >>>>        oid_value = 24131056}, next = 0x1720998}
>> >>>> ---- from ---
>> >>>> (gdb) p *list1->head->next->next->**next->next->next->next->next
>> >>>> $25 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>> >>>>        oid_value = 24250808}, next = 0x1721190}
>> >>>> (gdb) p
>> *list1->head->next->next->**next->next->next->next->next->**next
>> >>>> $26 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>> >>>>        oid_value = 24252848}, next = 0x1721988}
>> >>>> (gdb) p *list1->head->next->next->**next->next->next->next->next->**
>> >>>> next->next
>> >>>> $27 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>> >>>>        oid_value = 24254888}, next = 0x1722018}
>> >>>> (gdb) p
>> >>>> *list1->head->next->next->**next->next->next->next->next->**
>> >>>> next->next->next
>> >>>> $28 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>> >>>>        oid_value = 24256568}, next = 0x1722820}
>> >>>> (gdb) p
>> >>>>
>> >>>> *list1->head->next->next->**next->next->next->next->next->**
>> >>>> next->next->next->next
>> >>>> $29 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>> >>>>        oid_value = 24258624}, next = 0x0}
>> >>>> ---- to ----
>> >>>>
>> >>>> [list2]
>> >>>> (gdb) p *list2->head
>> >>>> $31 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
>> >>>>        oid_value = 24250808}, next = 0x1721190}
>> >>>> (gdb) p *list2->head->next
>> >>>> $32 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
>> >>>>        oid_value = 24252848}, next = 0x1721988}
>> >>>> (gdb) p *list2->head->next->next
>> >>>> $33 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
>> >>>>        oid_value = 24254888}, next = 0x1722018}
>> >>>> (gdb) p *list2->head->next->next->next
>> >>>> $34 = {data = {ptr_value = 0x1722038, int_value = 24256568,
>> >>>>        oid_value = 24256568}, next = 0x1722820}
>> >>>> (gdb) p *list2->head->next->next->**next->next
>> >>>> $35 = {data = {ptr_value = 0x1722840, int_value = 24258624,
>> >>>>        oid_value = 24258624}, next = 0x0}
>> >>>> ----
>> >>>>
>> >>>> list1's last five elements are same with list2's all elements.
>> >>>> (in above example, between "from" and "to" in list1 equal all of
>> list2)
>> >>>>
>> >>>> This is cause of infinitely roop, but I can not
>> >>>> watch deeper.
>> >>>> Because some values from gdb are optimized and un-displayed.
>> >>>> I tried compile with CFLAGS=O0, but I can't.
>> >>>>
>> >>>> What can I do more ?
>> >>>>
>> >>>> regards,
>> >>>> ------------------
>> >>>> NTT Software Corporation
>> >>>> Tomonari Katsumata
>> >>>>
>> >>>> (2013/06/12 21:04), Ashutosh Bapat wrote:
>> >>>>    > Hi Tomonari,
>> >>>>    > Can you please check the list's sanity before calling
>> >>>> pgxc_collect_RTE()
>> >>>>    > and at every point in the minions of this function. My primary
>> >>>> suspect
>> >>>> is
>> >>>>    > the line pgxcplan.c:3094. We should copy the list before
>> >>>> concatenating it.
>> >>>>    >
>> >>>>    >
>> >>>>    > On Wed, Jun 12, 2013 at 2:26 PM, Tomonari Katsumata <
>> >>>>    > kat...@po....**jp<
>> kat...@po...>>
>> >>>> wrote:
>> >>>>    >
>> >>>>    >> Hi Ashutosh,
>> >>>>    >>
>> >>>>    >> Thank you for the response.
>> >>>>    >>
>> >>>>    >> (2013/06/12 14:43), Ashutosh Bapat wrote:
>> >>>>    >>  >> Hi,
>> >>>>    >>  >> >
>> >>>>    >>  >> > I've investigated this problem(BUG:3614369).
>> >>>>    >>  >> >
>> >>>>    >>  >> > I caught the cause of it, but I can not
>> >>>>    >>  >> > find where to fix.
>> >>>>    >>  >> >
>> >>>>    >>  >> > The problem occurs when "pgxc_collect_RTE_walker" is
>> called
>> >>>>    >> infinitely.
>> >>>>    >>  >> > It seems that rtable(List of RangeTable) become cyclic
>> List.
>> >>>>    >>  >> > I'm not sure where the List is made.
>> >>>>    >>  >> >
>> >>>>    >>  >> >
>> >>>>    >>  > I guess, we are talking about EXECUTE DIRECT statement that
>> you
>> >>>> have
>> >>>>    >>  > mentioned earlier.
>> >>>>    >>
>> >>>>    >> Yes, that's right.
>> >>>>    >> I'm talking about EXECUTE DIRECT statement like below.
>> >>>>    >>   ---
>> >>>>    >>   EXECUTE DIRECT ON (data1) $$
>> >>>>    >>   SELECT
>> >>>>    >>   count(*)
>> >>>>    >>   FROM
>> >>>>    >>   (SELECT * FROM pg_locks l LEFT JOIN
>> >>>>    >>   (SELECT * FROM pg_stat_activity) s ON l.database = s.datid) a
>> >>>>    >>   $$
>> >>>>    >>   ---
>> >>>>    >>
>> >>>>    >>  > The function pgxc_collect_RTE_walker() is a recursive
>> >>>>    >>  > function. The condition to end the recursion is if the given
>> >>>> node is
>> >>>>    >> NULL.
>> >>>>    >>  > We have to look at if that condition is met and if not why.
>> >>>>    >>  >
>> >>>>    >> I investigated it deeper, and I noticed that
>> >>>>    >> the infinitely loop happens at the function
>> "range_table_walker()".
>> >>>>    >>
>> >>>>    >> Please see below trace.
>> >>>>    >> ===========================
>> >>>>    >> Breakpoint 1, range_table_walker (rtable=0x15e7968,
>> walker=0x612c70
>> >>>>    >> <pgxc_collect_RTE_walker>, context=0x7fffd2de31c0,
>> >>>>    >>      flags=0) at nodeFuncs.c:1908
>> >>>>    >> 1908    in nodeFuncs.c
>> >>>>    >>
>> >>>>    >> (gdb) p *rtable
>> >>>>    >> $10 = {type = T_List, length = 5, head = 0x15e7998, tail =
>> >>>> 0x15e9820}
>> >>>>    >> (gdb) p *rtable->head
>> >>>>    >> $11 = {data = {ptr_value = 0x15e79b8, int_value = 22968760,
>> >>>> oid_value =
>> >>>>    >> 22968760}, next = 0x15e8190}
>> >>>>    >> (gdb) p *rtable->head->next
>> >>>>    >> $12 = {data = {ptr_value = 0x15e81b0, int_value = 22970800,
>> >>>> oid_value =
>> >>>>    >> 22970800}, next = 0x15e8988}
>> >>>>    >> (gdb) p *rtable->head->next->next
>> >>>>    >> $13 = {data = {ptr_value = 0x15e89a8, int_value = 22972840,
>> >>>> oid_value =
>> >>>>    >> 22972840}, next = 0x15e9018}
>> >>>>    >> (gdb) p *rtable->head->next->next->**next
>> >>>>    >> $14 = {data = {ptr_value = 0x15e9038, int_value = 22974520,
>> >>>> oid_value =
>> >>>>    >> 22974520}, next = 0x15e9820}
>> >>>>    >> (gdb) p *rtable->head->next->next->**next->next
>> >>>>    >> $15 = {data = {ptr_value = 0x15e9840, int_value = 22976576,
>> >>>> oid_value =
>> >>>>    >> 22976576}, next = 0x15e7998}
>> >>>>    >> ===========================
>> >>>>    >>
>> >>>>    >> The line which starts with "$15" has 0x15e7998 as its next
>> data.
>> >>>>    >> But it is the head pointer(see the line which starts with $10).
>> >>>>    >>
>> >>>>    >> And in range_table_walker(), the function is called
>> recursively.
>> >>>>    >> --------
>> >>>>    >> ...
>> >>>>    >>          if (!(flags & QTW_IGNORE_RANGE_TABLE))
>> >>>>    >>          {
>> >>>>    >>                  if (range_table_walker(query->**rtable,
>> walker,
>> >>>> context,
>> >>>>    >> flags))
>> >>>>    >>                          return true;
>> >>>>    >>          }
>> >>>>    >> ...
>> >>>>    >> --------
>> >>>>    >>
>> >>>>    >> We should make rtable right or deal with "flags" properly.
>> >>>>    >> But I can't find where to do it...
>> >>>>    >>
>> >>>>    >> What do you think ?
>> >>>>    >>
>> >>>>    >> regards,
>> >>>>    >> ---------
>> >>>>    >> NTT Software Corporation
>> >>>>    >> Tomonari Katsumata
>> >>>>    >>
>> >>>>    >>
>> >>>>    >>
>> >>>>    >>
>> >>>>    >>
>> >>>>
>> >>>> ------------------------------**------------------------------**
>> >>>> ------------------
>> >>>>    >> This SF.net email is sponsored by Windows:
>> >>>>    >>
>> >>>>    >> Build for Windows Store.
>> >>>>    >>
>> >>>>    >> http://p.sf.net/sfu/windows-**dev2dev<
>> http://p.sf.net/sfu/windows-dev2dev>
>> >>>>    >> ______________________________**_________________
>> >>>>    >> Postgres-xc-developers mailing list
>> >>>>    >> Postgres-xc-developers@lists.**sourceforge.net<
>> Pos...@li...>
>> >>>>    >> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**
>> >>>> developers<
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
>> >>>>    >>
>> >>>>    >
>> >>>>    >
>> >>>>    >
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------**------------------------------**
>> >>>> ------------------
>> >>>> This SF.net email is sponsored by Windows:
>> >>>>
>> >>>> Build for Windows Store.
>> >>>>
>> >>>> http://p.sf.net/sfu/windows-**dev2dev<
>> http://p.sf.net/sfu/windows-dev2dev>
>> >>>> ______________________________**_________________
>> >>>> Postgres-xc-developers mailing list
>> >>>> Postgres-xc-developers@lists.**sourceforge.net<
>> Pos...@li...>
>> >>>>
>> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**developers<
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by Windows:
>> >>
>> >> Build for Windows Store.
>> >>
>> >> http://p.sf.net/sfu/windows-dev2dev
>> >> _______________________________________________
>> >> Postgres-xc-developers mailing list
>> >> Pos...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> >>
>> >>
>> >
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
-- 
*Abbas*
 Architect

Ph: 92.334.5100153
 Skype ID: gabbasb
www.enterprisedb.co
<http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
*
Follow us on Twitter*
@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars,
whitepapers<http://www.enterprisedb.com/resources-community>and
more<http://www.enterprisedb.com/resources-community>

Re: [Postgres-xc-developers] Query Planning bug ?

[鈴木 幸市 <ko...@in...>]

I suppose Abbas has good experience on how to run "make installcheck".

Is "make check" successful with the same code?
---
Koichi Suzuki



On 2013/07/01, at 20:51, Tomonari Katsumata <t.k...@gm...> wrote:

> Hi,
>  
> I've tried regression test, but I could not
> get right result.
> Both patched and un-patched Postgres-XC get
> same result, so I think my process is bad.
>  
> I run a gtm, a gtm_proxy, a coordinator, a datanode
> in one server(CentOS6.4 x86_64 on VMWare),
> and hit "make installcheck".
> The configure option is [--enable-debug CFLAGS=""].
>  
> What is right way to run the regression test?
>  
> output is below.
> ---------------------------------------------------------
> test tablespace               ... ok
> test boolean                  ... ok
> test char                     ... ok
> test name                     ... ok
> test varchar                  ... ok
> test text                     ... ok
> test int2                     ... ok
> test int4                     ... ok
> test int8                     ... ok
> test oid                      ... ok
> test float4                   ... ok
> test float8                   ... ok
> test bit                      ... ok
> test numeric                  ... ok
> test txid                     ... ok
> test uuid                     ... ok
> test enum                     ... FAILED
> test money                    ... ok
> test rangetypes               ... ok
> test strings                  ... ok
> test numerology               ... ok
> test point                    ... ok
> test lseg                     ... ok
> test box                      ... ok
> test path                     ... ok
> test polygon                  ... ok
> test circle                   ... ok
> test date                     ... ok
> test time                     ... ok
> test timetz                   ... ok
> test timestamp                ... ok
> test timestamptz              ... ok
> test interval                 ... ok
> test abstime                  ... ok
> test reltime                  ... ok
> test tinterval                ... ok
> test inet                     ... ok
> test macaddr                  ... ok
> test tstypes                  ... ok
> test comments                 ... ok
> test geometry                 ... ok
> test horology                 ... ok
> test regex                    ... ok
> test oidjoins                 ... ok
> test type_sanity              ... ok
> test opr_sanity               ... ok
> test insert                   ... ok
> test create_function_1        ... ok
> test create_type              ... ok
> test create_table             ... ok
> test create_function_2        ... ok
> test create_function_3        ... ok
> test copy                     ... ok
> test copyselect               ... ok
> test create_misc              ... ok
> test create_operator          ... ok
> test create_index             ... FAILED
> test create_view              ... ok
> test create_aggregate         ... ok
> test create_cast              ... ok
> test constraints              ... FAILED
> test triggers                 ... ok
> test inherit                  ... FAILED
> test create_table_like        ... ok
> test typed_table              ... ok
> test vacuum                   ... ok
> test drop_if_exists           ... ok
> test sanity_check             ... ok
> test errors                   ... ok
> test select                   ... ok
> test select_into              ... ok
> test select_distinct          ... ok
> test select_distinct_on       ... ok
> test select_implicit          ... ok
> test select_having            ... ok
> test subselect                ... ok
> test union                    ... ok
> test case                     ... ok
> test join                     ... FAILED
> test aggregates               ... FAILED
> test transactions             ... ok
> test random                   ... ok
> test portals                  ... ok
> test arrays                   ... FAILED
> test btree_index              ... ok
> test hash_index               ... ok
> test update                   ... ok
> test delete                   ... ok
> test namespace                ... ok
> test prepared_xacts           ... ok
> test privileges               ... FAILED
> test security_label           ... ok
> test collate                  ... FAILED
> test misc                     ... ok
> test rules                    ... ok
> test select_views             ... ok
> test portals_p2               ... ok
> test foreign_key              ... ok
> test cluster                  ... ok
> test dependency               ... ok
> test guc                      ... ok
> test bitmapops                ... ok
> test combocid                 ... ok
> test tsearch                  ... ok
> test tsdicts                  ... ok
> test foreign_data             ... ok
> test window                   ... ok
> test xmlmap                   ... FAILED (test process exited with exit code 2)
> test functional_deps          ... FAILED (test process exited with exit code 2)
> test advisory_lock            ... FAILED (test process exited with exit code 2)
> test json                     ... FAILED (test process exited with exit code 2)
> test plancache                ... FAILED (test process exited with exit code 2)
> test limit                    ... FAILED (test process exited with exit code 2)
> test plpgsql                  ... FAILED (test process exited with exit code 2)
> test copy2                    ... FAILED (test process exited with exit code 2)
> test temp                     ... FAILED (test process exited with exit code 2)
> test domain                   ... FAILED (test process exited with exit code 2)
> test rangefuncs               ... FAILED (test process exited with exit code 2)
> test prepare                  ... FAILED (test process exited with exit code 2)
> test without_oid              ... FAILED (test process exited with exit code 2)
> test conversion               ... FAILED (test process exited with exit code 2)
> test truncate                 ... FAILED (test process exited with exit code 2)
> test alter_table              ... FAILED (test process exited with exit code 2)
> test sequence                 ... FAILED (test process exited with exit code 2)
> test polymorphism             ... FAILED (test process exited with exit code 2)
> test rowtypes                 ... FAILED (test process exited with exit code 2)
> test returning                ... FAILED (test process exited with exit code 2)
> test largeobject              ... FAILED (test process exited with exit code 2)
> test with                     ... FAILED (test process exited with exit code 2)
> test xml                      ... FAILED (test process exited with exit code 2)
> test stats                    ... FAILED (test process exited with exit code 2)
> test xc_create_function       ... FAILED (test process exited with exit code 2)
> test xc_groupby               ... FAILED (test process exited with exit code 2)
> test xc_distkey               ... FAILED (test process exited with exit code 2)
> test xc_having                ... FAILED (test process exited with exit code 2)
> test xc_temp                  ... FAILED (test process exited with exit code 2)
> test xc_remote                ... FAILED (test process exited with exit code 2)
> test xc_node                  ... FAILED (test process exited with exit code 2)
> test xc_FQS                   ... FAILED (test process exited with exit code 2)
> test xc_FQS_join              ... FAILED (test process exited with exit code 2)
> test xc_misc                  ... FAILED (test process exited with exit code 2)
> test xc_triggers              ... FAILED (test process exited with exit code 2)
> test xc_trigship              ... FAILED (test process exited with exit code 2)
> test xc_constraints           ... FAILED (test process exited with exit code 2)
> test xc_copy                  ... FAILED (test process exited with exit code 2)
> test xc_alter_table           ... FAILED (test process exited with exit code 2)
> test xc_sequence              ... FAILED (test process exited with exit code 2)
> test xc_prepared_xacts        ... FAILED (test process exited with exit code 2)
> test xc_notrans_block         ... FAILED (test process exited with exit code 2)
> test xc_limit                 ... FAILED (test process exited with exit code 2)
> test xc_sort                  ... FAILED (test process exited with exit code 2)
> test xc_returning             ... FAILED (test process exited with exit code 2)
> test xc_params                ... FAILED (test process exited with exit code 2)
> =========================
>  55 of 153 tests failed.
> =========================
> 
> 
> 2013/7/1 Tomonari Katsumata <kat...@po...>
> Hi Ashutosh,
> 
> OK, I'll try regression test.
> Please wait for the result.
> 
> regards,
> ------------
> NTT Software Corporation
> Tomonari Katsumata
> 
> (2013/07/01 17:06), Ashutosh Bapat wrote:
> > Hi Tomonori,
> >
> >
> >
> > On Mon, Jul 1, 2013 at 1:33 PM, Tomonari Katsumata <
> > kat...@po...> wrote:
> >
> >> Hi Ashutosh and all,
> >>
> >> Sorry for late response.
> >> I made a patch for resolving the problem I mentioned before.
> >>
> >> I thought the reason of this problem is parsing query twice.
> >> because of this, the rtable is made from same Lists and become
> >> cycliced List.
> >> I fixed this problem with making former List empty.
> >>
> >> I'm not sure this fix leads any anothre problems but
> >> the problem query I mentioned before works fine.
> >>
> >> This patch is against for "**a074cac9b6b507e6d4b58c5004673f**6cc65fcde1".
> >>
> >>
> > You can check the robustness of patch by running regression. Please let me
> > know what you see.
> >
> >
> >> regards,
> >> ------------------
> >> NTT Software Corporation
> >> Tomonari Katsumata
> >>
> >>
> >> (2013/06/17 18:53), Ashutosh Bapat wrote:
> >>
> >>> Hi Tomonari,
> >>> In which function have you taken this debug info? What is list1 and list2?
> >>>
> >>>
> >>> On Mon, Jun 17, 2013 at 10:13 AM, Tomonari Katsumata <
> >>> kat...@po....**jp <kat...@po...>>
> >>> wrote:
> >>>
> >>>   Hi Ashtosh,
> >>>> Sorry for slow response.
> >>>>
> >>>> I've watched the each lists at list_concat function.
> >>>>
> >>>> This function is called several times, but the lists before
> >>>> last infinitely roop are like below.
> >>>>
> >>>> [list1]
> >>>> (gdb) p *list1->head
> >>>> $18 = {data = {ptr_value = 0x17030e8, int_value = 24129768,
> >>>>        oid_value = 24129768}, next = 0x170d418}
> >>>> (gdb) p *list1->head->next
> >>>> $19 = {data = {ptr_value = 0x17033d0, int_value = 24130512,
> >>>>        oid_value = 24130512}, next = 0x170fd40}
> >>>> (gdb) p *list1->head->next->next
> >>>> $20 = {data = {ptr_value = 0x170ae58, int_value = 24161880,
> >>>>        oid_value = 24161880}, next = 0x171e6c8}
> >>>> (gdb) p *list1->head->next->next->next
> >>>> $21 = {data = {ptr_value = 0x1702ca8, int_value = 24128680,
> >>>>        oid_value = 24128680}, next = 0x171ed28}
> >>>> (gdb) p *list1->head->next->next->**next->next
> >>>> $22 = {data = {ptr_value = 0x170af68, int_value = 24162152,
> >>>>        oid_value = 24162152}, next = 0x171f3a0}
> >>>> (gdb) p *list1->head->next->next->**next->next->next
> >>>> $23 = {data = {ptr_value = 0x170b0a8, int_value = 24162472,
> >>>>        oid_value = 24162472}, next = 0x170b7c0}
> >>>> (gdb) p *list1->head->next->next->**next->next->next->next
> >>>> $24 = {data = {ptr_value = 0x17035f0, int_value = 24131056,
> >>>>        oid_value = 24131056}, next = 0x1720998}
> >>>> ---- from ---
> >>>> (gdb) p *list1->head->next->next->**next->next->next->next->next
> >>>> $25 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
> >>>>        oid_value = 24250808}, next = 0x1721190}
> >>>> (gdb) p *list1->head->next->next->**next->next->next->next->next->**next
> >>>> $26 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
> >>>>        oid_value = 24252848}, next = 0x1721988}
> >>>> (gdb) p *list1->head->next->next->**next->next->next->next->next->**
> >>>> next->next
> >>>> $27 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
> >>>>        oid_value = 24254888}, next = 0x1722018}
> >>>> (gdb) p
> >>>> *list1->head->next->next->**next->next->next->next->next->**
> >>>> next->next->next
> >>>> $28 = {data = {ptr_value = 0x1722038, int_value = 24256568,
> >>>>        oid_value = 24256568}, next = 0x1722820}
> >>>> (gdb) p
> >>>>
> >>>> *list1->head->next->next->**next->next->next->next->next->**
> >>>> next->next->next->next
> >>>> $29 = {data = {ptr_value = 0x1722840, int_value = 24258624,
> >>>>        oid_value = 24258624}, next = 0x0}
> >>>> ---- to ----
> >>>>
> >>>> [list2]
> >>>> (gdb) p *list2->head
> >>>> $31 = {data = {ptr_value = 0x17209b8, int_value = 24250808,
> >>>>        oid_value = 24250808}, next = 0x1721190}
> >>>> (gdb) p *list2->head->next
> >>>> $32 = {data = {ptr_value = 0x17211b0, int_value = 24252848,
> >>>>        oid_value = 24252848}, next = 0x1721988}
> >>>> (gdb) p *list2->head->next->next
> >>>> $33 = {data = {ptr_value = 0x17219a8, int_value = 24254888,
> >>>>        oid_value = 24254888}, next = 0x1722018}
> >>>> (gdb) p *list2->head->next->next->next
> >>>> $34 = {data = {ptr_value = 0x1722038, int_value = 24256568,
> >>>>        oid_value = 24256568}, next = 0x1722820}
> >>>> (gdb) p *list2->head->next->next->**next->next
> >>>> $35 = {data = {ptr_value = 0x1722840, int_value = 24258624,
> >>>>        oid_value = 24258624}, next = 0x0}
> >>>> ----
> >>>>
> >>>> list1's last five elements are same with list2's all elements.
> >>>> (in above example, between "from" and "to" in list1 equal all of list2)
> >>>>
> >>>> This is cause of infinitely roop, but I can not
> >>>> watch deeper.
> >>>> Because some values from gdb are optimized and un-displayed.
> >>>> I tried compile with CFLAGS=O0, but I can't.
> >>>>
> >>>> What can I do more ?
> >>>>
> >>>> regards,
> >>>> ------------------
> >>>> NTT Software Corporation
> >>>> Tomonari Katsumata
> >>>>
> >>>> (2013/06/12 21:04), Ashutosh Bapat wrote:
> >>>>    > Hi Tomonari,
> >>>>    > Can you please check the list's sanity before calling
> >>>> pgxc_collect_RTE()
> >>>>    > and at every point in the minions of this function. My primary
> >>>> suspect
> >>>> is
> >>>>    > the line pgxcplan.c:3094. We should copy the list before
> >>>> concatenating it.
> >>>>    >
> >>>>    >
> >>>>    > On Wed, Jun 12, 2013 at 2:26 PM, Tomonari Katsumata <
> >>>>    > kat...@po....**jp<kat...@po...>>
> >>>> wrote:
> >>>>    >
> >>>>    >> Hi Ashutosh,
> >>>>    >>
> >>>>    >> Thank you for the response.
> >>>>    >>
> >>>>    >> (2013/06/12 14:43), Ashutosh Bapat wrote:
> >>>>    >>  >> Hi,
> >>>>    >>  >> >
> >>>>    >>  >> > I've investigated this problem(BUG:3614369).
> >>>>    >>  >> >
> >>>>    >>  >> > I caught the cause of it, but I can not
> >>>>    >>  >> > find where to fix.
> >>>>    >>  >> >
> >>>>    >>  >> > The problem occurs when "pgxc_collect_RTE_walker" is called
> >>>>    >> infinitely.
> >>>>    >>  >> > It seems that rtable(List of RangeTable) become cyclic List.
> >>>>    >>  >> > I'm not sure where the List is made.
> >>>>    >>  >> >
> >>>>    >>  >> >
> >>>>    >>  > I guess, we are talking about EXECUTE DIRECT statement that you
> >>>> have
> >>>>    >>  > mentioned earlier.
> >>>>    >>
> >>>>    >> Yes, that's right.
> >>>>    >> I'm talking about EXECUTE DIRECT statement like below.
> >>>>    >>   ---
> >>>>    >>   EXECUTE DIRECT ON (data1) $$
> >>>>    >>   SELECT
> >>>>    >>   count(*)
> >>>>    >>   FROM
> >>>>    >>   (SELECT * FROM pg_locks l LEFT JOIN
> >>>>    >>   (SELECT * FROM pg_stat_activity) s ON l.database = s.datid) a
> >>>>    >>   $$
> >>>>    >>   ---
> >>>>    >>
> >>>>    >>  > The function pgxc_collect_RTE_walker() is a recursive
> >>>>    >>  > function. The condition to end the recursion is if the given
> >>>> node is
> >>>>    >> NULL.
> >>>>    >>  > We have to look at if that condition is met and if not why.
> >>>>    >>  >
> >>>>    >> I investigated it deeper, and I noticed that
> >>>>    >> the infinitely loop happens at the function "range_table_walker()".
> >>>>    >>
> >>>>    >> Please see below trace.
> >>>>    >> ===========================
> >>>>    >> Breakpoint 1, range_table_walker (rtable=0x15e7968, walker=0x612c70
> >>>>    >> <pgxc_collect_RTE_walker>, context=0x7fffd2de31c0,
> >>>>    >>      flags=0) at nodeFuncs.c:1908
> >>>>    >> 1908    in nodeFuncs.c
> >>>>    >>
> >>>>    >> (gdb) p *rtable
> >>>>    >> $10 = {type = T_List, length = 5, head = 0x15e7998, tail =
> >>>> 0x15e9820}
> >>>>    >> (gdb) p *rtable->head
> >>>>    >> $11 = {data = {ptr_value = 0x15e79b8, int_value = 22968760,
> >>>> oid_value =
> >>>>    >> 22968760}, next = 0x15e8190}
> >>>>    >> (gdb) p *rtable->head->next
> >>>>    >> $12 = {data = {ptr_value = 0x15e81b0, int_value = 22970800,
> >>>> oid_value =
> >>>>    >> 22970800}, next = 0x15e8988}
> >>>>    >> (gdb) p *rtable->head->next->next
> >>>>    >> $13 = {data = {ptr_value = 0x15e89a8, int_value = 22972840,
> >>>> oid_value =
> >>>>    >> 22972840}, next = 0x15e9018}
> >>>>    >> (gdb) p *rtable->head->next->next->**next
> >>>>    >> $14 = {data = {ptr_value = 0x15e9038, int_value = 22974520,
> >>>> oid_value =
> >>>>    >> 22974520}, next = 0x15e9820}
> >>>>    >> (gdb) p *rtable->head->next->next->**next->next
> >>>>    >> $15 = {data = {ptr_value = 0x15e9840, int_value = 22976576,
> >>>> oid_value =
> >>>>    >> 22976576}, next = 0x15e7998}
> >>>>    >> ===========================
> >>>>    >>
> >>>>    >> The line which starts with "$15" has 0x15e7998 as its next data.
> >>>>    >> But it is the head pointer(see the line which starts with $10).
> >>>>    >>
> >>>>    >> And in range_table_walker(), the function is called recursively.
> >>>>    >> --------
> >>>>    >> ...
> >>>>    >>          if (!(flags & QTW_IGNORE_RANGE_TABLE))
> >>>>    >>          {
> >>>>    >>                  if (range_table_walker(query->**rtable, walker,
> >>>> context,
> >>>>    >> flags))
> >>>>    >>                          return true;
> >>>>    >>          }
> >>>>    >> ...
> >>>>    >> --------
> >>>>    >>
> >>>>    >> We should make rtable right or deal with "flags" properly.
> >>>>    >> But I can't find where to do it...
> >>>>    >>
> >>>>    >> What do you think ?
> >>>>    >>
> >>>>    >> regards,
> >>>>    >> ---------
> >>>>    >> NTT Software Corporation
> >>>>    >> Tomonari Katsumata
> >>>>    >>
> >>>>    >>
> >>>>    >>
> >>>>    >>
> >>>>    >>
> >>>>
> >>>> ------------------------------**------------------------------**
> >>>> ------------------
> >>>>    >> This SF.net email is sponsored by Windows:
> >>>>    >>
> >>>>    >> Build for Windows Store.
> >>>>    >>
> >>>>    >> http://p.sf.net/sfu/windows-**dev2dev<http://p.sf.net/sfu/windows-dev2dev>
> >>>>    >> ______________________________**_________________
> >>>>    >> Postgres-xc-developers mailing list
> >>>>    >> Postgres-xc-developers@lists.**sourceforge.net<Pos...@li...>
> >>>>    >> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**
> >>>> developers<https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
> >>>>    >>
> >>>>    >
> >>>>    >
> >>>>    >
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------**------------------------------**
> >>>> ------------------
> >>>> This SF.net email is sponsored by Windows:
> >>>>
> >>>> Build for Windows Store.
> >>>>
> >>>> http://p.sf.net/sfu/windows-**dev2dev<http://p.sf.net/sfu/windows-dev2dev>
> >>>> ______________________________**_________________
> >>>> Postgres-xc-developers mailing list
> >>>> Postgres-xc-developers@lists.**sourceforge.net<Pos...@li...>
> >>>> https://lists.sourceforge.net/**lists/listinfo/postgres-xc-**developers<https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers>
> >>>>
> >>>>
> >>>
> >>
> >> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by Windows:
> >>
> >> Build for Windows Store.
> >>
> >> http://p.sf.net/sfu/windows-dev2dev
> >> _______________________________________________
> >> Postgres-xc-developers mailing list
> >> Pos...@li...
> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >>
> >>
> >
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Re: [Postgres-xc-developers] Query Planning bug ?

[Ashutosh B. <ash...@en...>]

Hi Tomonari,
In the output you can see a lot of test process exited with exit code 2,
which implies that there was a server crash while running the test. So,
certainly there is something wrong in the patch.

In pgxc_collect_RTE_walker()

3112         crte_context->crte_rtable =
list_concat(crte_context->crte_rtable,
3113                                                 query->rtable);

see if copying query->rtable solves the issue. The changed code would look
like

3112         crte_context->crte_rtable =
list_concat(crte_context->crte_rtable,
3113
list_copy(query->rtable));



On Tue, Jul 2, 2013 at 6:50 AM, Tomonari Katsumata <
kat...@po...> wrote:

>  Hi,
>
>   I've tried regression test, but I could not
> get right result.
> Both patched and un-patched Postgres-XC get
> same result, so I think my process is bad.
>
> I run a gtm, a gtm_proxy, a coordinator, a datanode
> in one server(CentOS6.4 x86_64 on VMWare),
> and hit "make installcheck".
>
> The configure option is [--enable-debug CFLAGS=""].
>   What is right way to run the regression test?
>
> output is below.
> ------------------------------**---------------------------
> test tablespace ... ok
> test boolean ... ok
> test char ... ok
> test name ... ok
> test varchar ... ok
> test text ... ok
> test int2 ... ok
> test int4 ... ok
> test int8 ... ok
> test oid ... ok
> test float4 ... ok
> test float8 ... ok
> test bit ... ok
> test numeric ... ok
> test txid ... ok
> test uuid ... ok
> test enum ... FAILED
> test money ... ok
> test rangetypes ... ok
> test strings ... ok
> test numerology ... ok
> test point ... ok
> test lseg ... ok
> test box ... ok
> test path ... ok
> test polygon ... ok
> test circle ... ok
> test date ... ok
> test time ... ok
> test timetz ... ok
> test timestamp ... ok
> test timestamptz ... ok
> test interval ... ok
> test abstime ... ok
> test reltime ... ok
> test tinterval ... ok
> test inet ... ok
> test macaddr ... ok
> test tstypes ... ok
> test comments ... ok
> test geometry ... ok
> test horology ... ok
> test regex ... ok
> test oidjoins ... ok
> test type_sanity ... ok
> test opr_sanity ... ok
> test insert ... ok
> test create_function_1 ... ok
> test create_type ... ok
> test create_table ... ok
> test create_function_2 ... ok
> test create_function_3 ... ok
> test copy ... ok
> test copyselect ... ok
> test create_misc ... ok
> test create_operator ... ok
> test create_index ... FAILED
> test create_view ... ok
> test create_aggregate ... ok
> test create_cast ... ok
> test constraints ... FAILED
> test triggers ... ok
> test inherit ... FAILED
> test create_table_like ... ok
> test typed_table ... ok
> test vacuum ... ok
> test drop_if_exists ... ok
> test sanity_check ... ok
> test errors ... ok
> test select ... ok
> test select_into ... ok
> test select_distinct ... ok
> test select_distinct_on ... ok
> test select_implicit ... ok
> test select_having ... ok
> test subselect ... ok
> test union ... ok
> test case ... ok
> test join ... FAILED
> test aggregates ... FAILED
> test transactions ... ok
> test random ... ok
> test portals ... ok
> test arrays ... FAILED
> test btree_index ... ok
> test hash_index ... ok
> test update ... ok
> test delete ... ok
> test namespace ... ok
> test prepared_xacts ... ok
> test privileges ... FAILED
> test security_label ... ok
> test collate ... FAILED
> test misc ... ok
> test rules ... ok
> test select_views ... ok
> test portals_p2 ... ok
> test foreign_key ... ok
> test cluster ... ok
> test dependency ... ok
> test guc ... ok
> test bitmapops ... ok
> test combocid ... ok
> test tsearch ... ok
> test tsdicts ... ok
> test foreign_data ... ok
> test window ... ok
> test xmlmap ... FAILED (test process exited with exit code 2)
> test functional_deps ... FAILED (test process exited with exit code 2)
> test advisory_lock ... FAILED (test process exited with exit code 2)
> test json ... FAILED (test process exited with exit code 2)
> test plancache ... FAILED (test process exited with exit code 2)
> test limit ... FAILED (test process exited with exit code 2)
> test plpgsql ... FAILED (test process exited with exit code 2)
> test copy2 ... FAILED (test process exited with exit code 2)
> test temp ... FAILED (test process exited with exit code 2)
> test domain ... FAILED (test process exited with exit code 2)
> test rangefuncs ... FAILED (test process exited with exit code 2)
> test prepare ... FAILED (test process exited with exit code 2)
> test without_oid ... FAILED (test process exited with exit code 2)
> test conversion ... FAILED (test process exited with exit code 2)
> test truncate ... FAILED (test process exited with exit code 2)
> test alter_table ... FAILED (test process exited with exit code 2)
> test sequence ... FAILED (test process exited with exit code 2)
> test polymorphism ... FAILED (test process exited with exit code 2)
> test rowtypes ... FAILED (test process exited with exit code 2)
> test returning ... FAILED (test process exited with exit code 2)
> test largeobject ... FAILED (test process exited with exit code 2)
> test with ... FAILED (test process exited with exit code 2)
> test xml ... FAILED (test process exited with exit code 2)
> test stats ... FAILED (test process exited with exit code 2)
> test xc_create_function ... FAILED (test process exited with exit code 2)
> test xc_groupby ... FAILED (test process exited with exit code 2)
> test xc_distkey ... FAILED (test process exited with exit code 2)
> test xc_having ... FAILED (test process exited with exit code 2)
> test xc_temp ... FAILED (test process exited with exit code 2)
> test xc_remote ... FAILED (test process exited with exit code 2)
> test xc_node ... FAILED (test process exited with exit code 2)
> test xc_FQS ... FAILED (test process exited with exit code 2)
> test xc_FQS_join ... FAILED (test process exited with exit code 2)
> test xc_misc ... FAILED (test process exited with exit code 2)
> test xc_triggers ... FAILED (test process exited with exit code 2)
> test xc_trigship ... FAILED (test process exited with exit code 2)
> test xc_constraints ... FAILED (test process exited with exit code 2)
> test xc_copy ... FAILED (test process exited with exit code 2)
> test xc_alter_table ... FAILED (test process exited with exit code 2)
> test xc_sequence ... FAILED (test process exited with exit code 2)
> test xc_prepared_xacts ... FAILED (test process exited with exit code 2)
> test xc_notrans_block ... FAILED (test process exited with exit code 2)
> test xc_limit ... FAILED (test process exited with exit code 2)
> test xc_sort ... FAILED (test process exited with exit code 2)
> test xc_returning ... FAILED (test process exited with exit code 2)
> test xc_params ... FAILED (test process exited with exit code 2)
> =========================
> 55 of 153 tests failed.
> =========================
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company

Re: [Postgres-xc-developers] Query Planning bug ?

[Tomonari K. <kat...@po...>]

Hi,

I've tried regression test, but I could not
get right result.
Both patched and un-patched Postgres-XC get
same result, so I think my process is bad.

I run a gtm, a gtm_proxy, a coordinator, a datanode
in one server(CentOS6.4 x86_64 on VMWare),
and hit "make installcheck".

The configure option is [--enable-debug CFLAGS=""].
What is right way to run the regression test?

output is below.
---------------------------------------------------------
test tablespace ... ok
test boolean ... ok
test char ... ok
test name ... ok
test varchar ... ok
test text ... ok
test int2 ... ok
test int4 ... ok
test int8 ... ok
test oid ... ok
test float4 ... ok
test float8 ... ok
test bit ... ok
test numeric ... ok
test txid ... ok
test uuid ... ok
test enum ... FAILED
test money ... ok
test rangetypes ... ok
test strings ... ok
test numerology ... ok
test point ... ok
test lseg ... ok
test box ... ok
test path ... ok
test polygon ... ok
test circle ... ok
test date ... ok
test time ... ok
test timetz ... ok
test timestamp ... ok
test timestamptz ... ok
test interval ... ok
test abstime ... ok
test reltime ... ok
test tinterval ... ok
test inet ... ok
test macaddr ... ok
test tstypes ... ok
test comments ... ok
test geometry ... ok
test horology ... ok
test regex ... ok
test oidjoins ... ok
test type_sanity ... ok
test opr_sanity ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test create_function_3 ... ok
test copy ... ok
test copyselect ... ok
test create_misc ... ok
test create_operator ... ok
test create_index ... FAILED
test create_view ... ok
test create_aggregate ... ok
test create_cast ... ok
test constraints ... FAILED
test triggers ... ok
test inherit ... FAILED
test create_table_like ... ok
test typed_table ... ok
test vacuum ... ok
test drop_if_exists ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
test select_into ... ok
test select_distinct ... ok
test select_distinct_on ... ok
test select_implicit ... ok
test select_having ... ok
test subselect ... ok
test union ... ok
test case ... ok
test join ... FAILED
test aggregates ... FAILED
test transactions ... ok
test random ... ok
test portals ... ok
test arrays ... FAILED
test btree_index ... ok
test hash_index ... ok
test update ... ok
test delete ... ok
test namespace ... ok
test prepared_xacts ... ok
test privileges ... FAILED
test security_label ... ok
test collate ... FAILED
test misc ... ok
test rules ... ok
test select_views ... ok
test portals_p2 ... ok
test foreign_key ... ok
test cluster ... ok
test dependency ... ok
test guc ... ok
test bitmapops ... ok
test combocid ... ok
test tsearch ... ok
test tsdicts ... ok
test foreign_data ... ok
test window ... ok
test xmlmap ... FAILED (test process exited with exit code 2)
test functional_deps ... FAILED (test process exited with exit code 2)
test advisory_lock ... FAILED (test process exited with exit code 2)
test json ... FAILED (test process exited with exit code 2)
test plancache ... FAILED (test process exited with exit code 2)
test limit ... FAILED (test process exited with exit code 2)
test plpgsql ... FAILED (test process exited with exit code 2)
test copy2 ... FAILED (test process exited with exit code 2)
test temp ... FAILED (test process exited with exit code 2)
test domain ... FAILED (test process exited with exit code 2)
test rangefuncs ... FAILED (test process exited with exit code 2)
test prepare ... FAILED (test process exited with exit code 2)
test without_oid ... FAILED (test process exited with exit code 2)
test conversion ... FAILED (test process exited with exit code 2)
test truncate ... FAILED (test process exited with exit code 2)
test alter_table ... FAILED (test process exited with exit code 2)
test sequence ... FAILED (test process exited with exit code 2)
test polymorphism ... FAILED (test process exited with exit code 2)
test rowtypes ... FAILED (test process exited with exit code 2)
test returning ... FAILED (test process exited with exit code 2)
test largeobject ... FAILED (test process exited with exit code 2)
test with ... FAILED (test process exited with exit code 2)
test xml ... FAILED (test process exited with exit code 2)
test stats ... FAILED (test process exited with exit code 2)
test xc_create_function ... FAILED (test process exited with exit code 2)
test xc_groupby ... FAILED (test process exited with exit code 2)
test xc_distkey ... FAILED (test process exited with exit code 2)
test xc_having ... FAILED (test process exited with exit code 2)
test xc_temp ... FAILED (test process exited with exit code 2)
test xc_remote ... FAILED (test process exited with exit code 2)
test xc_node ... FAILED (test process exited with exit code 2)
test xc_FQS ... FAILED (test process exited with exit code 2)
test xc_FQS_join ... FAILED (test process exited with exit code 2)
test xc_misc ... FAILED (test process exited with exit code 2)
test xc_triggers ... FAILED (test process exited with exit code 2)
test xc_trigship ... FAILED (test process exited with exit code 2)
test xc_constraints ... FAILED (test process exited with exit code 2)
test xc_copy ... FAILED (test process exited with exit code 2)
test xc_alter_table ... FAILED (test process exited with exit code 2)
test xc_sequence ... FAILED (test process exited with exit code 2)
test xc_prepared_xacts ... FAILED (test process exited with exit code 2)
test xc_notrans_block ... FAILED (test process exited with exit code 2)
test xc_limit ... FAILED (test process exited with exit code 2)
test xc_sort ... FAILED (test process exited with exit code 2)
test xc_returning ... FAILED (test process exited with exit code 2)
test xc_params ... FAILED (test process exited with exit code 2)
=========================
55 of 153 tests failed.
=========================