Re: [Postgres-xc-bugs] A bug about sub-transaction in data node.

[ZhangJulian <jul...@ou...>]

oh, I see,thanks!

How about adding some error thrown once it goes to the sub-transaction code?

From: ko...@in...
To: jul...@ou...
CC: pos...@li...
Subject: Re: [Postgres-xc-bugs] A bug about sub-transaction in data node.
Date: Tue, 17 Jun 2014 11:03:56 +0000






Unfortunately, sub transaction is not supported by XC so far,   As you may know, this is the main reason why XC has several restriction in functions, which is originated by subtransaction nature in SPI module.



Regards;

---
Koichi Suzuki




2014/06/17 19:19、ZhangJulian <jul...@ou...> のメル：



Hi All,



The reproced steps:

===================================

postgres=# drop table if exists t1;

DROP TABLE

postgres=# create table t1 (c1 int, c2 int) distribute by hash(c1);

CREATE TABLE

postgres=# create or replace function myfun() returns void

language plpgsql

as $$

begin

insert into t1 values(1,1); 

EXCEPTION                   

WHEN serialization_failure OR deadlock_detected OR no_data_found

THEN ROLLBACK;                                                  

END;                                                   

$$;                                                  

CREATE FUNCTION

postgres=# select myfun();

 myfun 

-------

 

(1 row)



postgres=# select * from t1;

 c1 | c2 

----+----

(0 rows)



postgres=# \q

[pgxc@node1 ~]$ pgxc_ctl Psql - coord1 postgres

.....

postgres=# select * from t1;

 c1 | c2 

----+----

  1 |  1

(1 row)

============================

You can see in the first session, SELECT return 0 rows, but if you quit the session and open a new session, SELECT will return 1 rows.



I had debugged it for several days, the reason is the "EXCEPTION" block in myfun() will start a new sub-transaction. But when "select myfun();" finished, in the datanode, the sub-transaction is committed, but its parent transaction is still keeping alive, which
 cause the next SELECT think the row has not been commited. 

If you close the session, the parent session will be committed, then the SELECT will see the insertted rows.




I think I had found the reason, but I don't know what is the correct behavior when parent/sub transaction meets the coordinator/datanode. 


1. In the coordinator, the sub-transacton should be committed once the parent transaction is committed? Or they should committed separately? 


2. How datanode know two transactions is parent-child relation?

3. Coordinator should tell datanode to commit child transaction explicitly? 



Thanks!

Julian



------------------------------------------------------------------------------

HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions

Find What Matters Most in Your Big Data with HPCC Systems

Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.

Leverages Graph Analysis for Fast Processing & Easy Data Exploration

http://p.sf.net/sfu/hpccsystems_______________________________________________

Postgres-xc-bugs mailing list

Pos...@li...

https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs