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

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

Year, please let me try.   At present, XC puts a message when SAVEPOINT is invoked.   It is internal code.

Thanks.
---
Koichi Suzuki

2014/06/17 21:57、ZhangJulian <jul...@ou...<mailto:jul...@ou...>> のメール：

oh, I see,thanks!

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

________________________________
From: ko...@in...<mailto:ko...@in...>
To: jul...@ou...<mailto:jul...@ou...>
CC: pos...@li...<mailto: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...<mailto: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...<mailto:Pos...@li...>
https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs