postgres-xc-developers Mailing List for Postgres-XC (Page 4)

Thanks a lot for pointing out.   Could you submit a patch for this?
2014/07/24 13:09 "Pavan Deolasee" <pav...@gm...>:

> Hello All,
>
> AFAICS that pgxc_ctl uses popen() at many places to execute a command and
> sometimes to also parse back the output. I've been chasing a bug that would
> cause subsequent reads on the FILE * returned by popen() to return EOF.
> After some investigations, it seems that the correct way to close the file
> descriptor returned by popen() is to use pclose() which fclose() does not
> reset the pipe state properly whereas pclose() does. The current XC code
> uses fclose() instead which probably works fine on some platforms such as
> Linux, but fails on other such as Mac OSX.
>
> Should we consider replacing fclose() with pclose() for pipes opened by
> popen()?
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>

Hello All,

AFAICS that pgxc_ctl uses popen() at many places to execute a command and
sometimes to also parse back the output. I've been chasing a bug that would
cause subsequent reads on the FILE * returned by popen() to return EOF.
After some investigations, it seems that the correct way to close the file
descriptor returned by popen() is to use pclose() which fclose() does not
reset the pipe state properly whereas pclose() does. The current XC code
uses fclose() instead which probably works fine on some platforms such as
Linux, but fails on other such as Mac OSX.

Should we consider replacing fclose() with pclose() for pipes opened by
popen()?

Thanks,
Pavan

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

My apologies. It was meant for XL list.

Thanks,
Pavan


On Fri, Jul 18, 2014 at 8:32 PM, Koichi Suzuki <koi...@gm...>
wrote:

> The patch looks specific to XL and I don' t understand the directive
> #ifdef XCP in bash script.   Could I have more explanation on this?
> ---
> Koichi Suzuki
>
>
> 2014-07-18 15:04 GMT+09:00 Pavan Deolasee <pav...@gm...>:
> > Hello,
> >
> > AFAICS contrib/pgxc_ctl/pgxc_ctl_bash.c is auto generated from dependent
> > files such as pgxc_ctl_bash_2. We have one version of pgxc_ctl_bash.c
> > checked in the repository which contains logic to read the datanode
> pooler
> > ports information correctly. But if the file gets overwritten during
> build
> > process, we lose those changes. How about applying the attached patch?
> >
> > Thanks,
> > Pavan
> >
> > --
> > Pavan Deolasee
> > http://www.linkedin.com/in/pavandeolasee
> >
> >
> ------------------------------------------------------------------------------
> > Want fast and easy access to all the code in your enterprise? Index and
> > search up to 200,000 lines of code with a free copy of Black Duck
> > Code Sight - the same software that powers the world's largest code
> > search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
>



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

The patch looks specific to XL and I don' t understand the directive
#ifdef XCP in bash script.   Could I have more explanation on this?
---
Koichi Suzuki


2014-07-18 15:04 GMT+09:00 Pavan Deolasee <pav...@gm...>:
> Hello,
>
> AFAICS contrib/pgxc_ctl/pgxc_ctl_bash.c is auto generated from dependent
> files such as pgxc_ctl_bash_2. We have one version of pgxc_ctl_bash.c
> checked in the repository which contains logic to read the datanode pooler
> ports information correctly. But if the file gets overwritten during build
> process, we lose those changes. How about applying the attached patch?
>
> Thanks,
> Pavan
>
> --
> Pavan Deolasee
> http://www.linkedin.com/in/pavandeolasee
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

On Fri, Jul 18, 2014 at 3:26 PM, Pavan Deolasee
<pav...@gm...> wrote:
> I think its a bad idea to use killall to terminate existing processes. I
> noticed this for GTM, but the  same may apply to other kinds of processes
> too. In my case, I was setting up GTM master and standby on the same
> machine. pgxc_ctl was failing to start up GTM correctly. Upon investigation,
> I figured out that while initialising/starting GTM slave, it first kills any
> existing GTM processes using "killall gtm". This kills the GTM master as
> well.
>
> There are several issues with using killall
>
> 1. It may kill unrelated processes e.g. I'd a vim session on gtm_cmd.c and
> it got killed too
That's actually kind of funny, just laughed lonely in front of my screen.

> 2. It may kill processes belonging to another instance, if user is running
> multiple database clusters on the same machine
This one is less funny :(

> 3. killall -9 It doesn't do a clean shutdown which may cause issues
> I wonder why can't we just rely on -m immediate? If the process fails to
> respond to that, either we have a bug to fix or worst administrator can
> manually kill the processes he wants. Even if we have to use kill command,
> can we not read PID from the .pid file and send signal to that particular
> process only?
Clearly. Partially written WAL record is an example of a bad thing
that could happen for Postgres. For GTM there are for sure similar
race conditions with a standby. The same applies to Postgres as well.
The usual, recommended, way is to use pg_ctl stop -m immediate in the
worst case. Isn't XC bundled with gtm_ctl that could be used instead
of killall? That's the same as sending a SIGQUIT after scanning the
GTM PID though..

Regards,
-- 
Michael

Hello,

I think its a bad idea to use killall to terminate existing processes. I
noticed this for GTM, but the  same may apply to other kinds of processes
too. In my case, I was setting up GTM master and standby on the same
machine. pgxc_ctl was failing to start up GTM correctly. Upon
investigation, I figured out that while initialising/starting GTM slave, it
first kills any existing GTM processes using "killall gtm". This kills the
GTM master as well.

There are several issues with using killall

1. It may kill unrelated processes e.g. I'd a vim session on gtm_cmd.c and
it got killed too
2. It may kill processes belonging to another instance, if user is running
multiple database clusters on the same machine
3. killall -9 It doesn't do a clean shutdown which may cause issues

I wonder why can't we just rely on -m immediate? If the process fails to
respond to that, either we have a bug to fix or worst administrator can
manually kill the processes he wants. Even if we have to use kill command,
can we not read PID from the .pid file and send signal to that particular
process only?

Thanks,
Pavan

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

I applied the fix to 1.1, 1.2 and master.  1.0 does not accept this fix.

Thank you ;
---
Koichi Suzuki


2014-07-02 11:24 GMT+09:00 Koichi Suzuki <koi...@gm...>:
> Thank you Mark for the fix.
>
> It looks reasonable and should go to all the versions.   I'll commit it soon.
> ---
> Koichi Suzuki
>
>
> 2014-07-01 23:05 GMT+09:00 Mark, Stefan <Ste...@se...>:
>> Hallo,
>>
>> there's a problem in postgres-xc v1.1 (and maybe also in other versions) that data that contains "\" and column separator is not replicated correctly to newly added data nodes. After some investigation we figured out that "\" and column separator are not quoted. The appended patch fixes this problem.
>>
>> Regards
>> Stefan
>>
>> --
>> Dipl. Inf.
>> Stefan Mark
>> Consultant
>> Public Sector
>> secunet Security Networks AG
>>
>>
>> Phone: +49-201-5454-3583, Fax: +49-201-5454-1323
>> E-Mail: ste...@se...
>> Ammonstraße 64, 01067 Dresden, Germany
>> www.secunet.com
>>
>> ______________________________________________________________________
>>
>> Registered at: Kronprinzenstraße 30, 45128 Essen, Deutschland
>> Amtsgericht Essen HRB 13615
>> Management Board: Dr Rainer Baumgart (CEO), Willem Bulthuis, Thomas Pleines
>> Chairman of Supervisory Board: Dr Peter Zattler
>> ______________________________________________________________________
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>

Thank you Mark for the fix.

It looks reasonable and should go to all the versions.   I'll commit it soon.
---
Koichi Suzuki


2014-07-01 23:05 GMT+09:00 Mark, Stefan <Ste...@se...>:
> Hallo,
>
> there's a problem in postgres-xc v1.1 (and maybe also in other versions) that data that contains "\" and column separator is not replicated correctly to newly added data nodes. After some investigation we figured out that "\" and column separator are not quoted. The appended patch fixes this problem.
>
> Regards
> Stefan
>
> --
> Dipl. Inf.
> Stefan Mark
> Consultant
> Public Sector
> secunet Security Networks AG
>
>
> Phone: +49-201-5454-3583, Fax: +49-201-5454-1323
> E-Mail: ste...@se...
> Ammonstraße 64, 01067 Dresden, Germany
> www.secunet.com
>
> ______________________________________________________________________
>
> Registered at: Kronprinzenstraße 30, 45128 Essen, Deutschland
> Amtsgericht Essen HRB 13615
> Management Board: Dr Rainer Baumgart (CEO), Willem Bulthuis, Thomas Pleines
> Chairman of Supervisory Board: Dr Peter Zattler
> ______________________________________________________________________
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Hallo,

there's a problem in postgres-xc v1.1 (and maybe also in other versions) that data that contains "\" and column separator is not replicated correctly to newly added data nodes. After some investigation we figured out that "\" and column separator are not quoted. The appended patch fixes this problem.

Regards
Stefan

-- 
Dipl. Inf.
Stefan Mark
Consultant
Public Sector
secunet Security Networks AG 


Phone: +49-201-5454-3583, Fax: +49-201-5454-1323
E-Mail: ste...@se...
Ammonstraße 64, 01067 Dresden, Germany
www.secunet.com

______________________________________________________________________

Registered at: Kronprinzenstraße 30, 45128 Essen, Deutschland 
Amtsgericht Essen HRB 13615
Management Board: Dr Rainer Baumgart (CEO), Willem Bulthuis, Thomas Pleines 
Chairman of Supervisory Board: Dr Peter Zattler
______________________________________________________________________

You can find answers in this report.
 * https://www.pgecons.org/downloads/43
While this is also written in Japanese, you can apply a machine
translator. You can copy and paste all sentences including texts in
the figure.

Rough summary of their considerations is...
 * Why the perf result of PostgreSQL decreased -> they had much
memories and high-performance CPU in 2012 compared to 2013.
 * Why the 4XCnode is much more than 4 times faster -> 4X cache
memories (sum of cache memory in all data nodes) gave such
improvement.

On 16 June 2014 13:42, wormwang <wor...@ya...> wrote:
> Why the perf result of PostgreSQL decreased from 2084 to 910 at  2012 to
> 2013 at the Pgbench results?
> and Why the 4XCnode is much more than 4 times faster than 1 PostgreSQL?
>
> -worm
>
> On 2014/6/16 9:18, 鈴木 幸市 wrote:
>> Scalability result for DBT-1 will be found at https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability
>> which is linked from the main page of Postgres-XC Wiki, https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Main_Page
>>
>> Pgbench result has been published at https://www.pgecons.org/wp-content/uploads/2014/pgecons2013png/wg1_scale-out.png
>> Sorry, it is in Japanese.
>>
>> Regards;
>> ---
>> Koichi Suzuki
>>
>> 2014/06/15 19:32、wormwang <wor...@ya...> のメール：
>>
>>> Hi! guys
>>>    I want studying Postgres-XC v1.2 for new project. I
>>>    Where is the benchmark testing of Postgres-XC? I saw a old benchmark
>>> in Website, I can't find it now.
>>>
>>> -worm
>>>
>>> ------------------------------------------------------------------------------
>>> 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-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>
>
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hello;

This is to announce the renewal of Postgres-XC roadmap and bug list page, at
https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Roadmap
and https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Bugs

Now roadmap and its priority is subject to open discussion/input/proposal.

It is very helpful to have an input of usecase of the feature, more
bug report and to share your experience with XC.

Best Regards;
---
Koichi Suzuki

On Mon, Jun 16, 2014 at 6:31 PM, 鈴木 幸市 <ko...@in...> wrote:
> As much as I heard, their benchmark in 2012 was not correct.   I had some talk with PGECons people and they made several correction on it.
> ---
> Koichi Suzuki
>
> 2014/06/16 13:42、wormwang <wor...@ya...> のメール：
>
>> Why the perf result of PostgreSQL decreased from 2084 to 910 at  2012 to 2013 at the Pgbench results?
>> and Why the 4XCnode is much more than 4 times faster than 1 PostgreSQL?
Btw, it is hard to give to those tests much value without more details about:
- The hardware used. How many CPUs? How much memory?
- The settings of server, like postgresql.conf. How many shared
buffers? Was catalog and/or pgbench data cached? pre-warmed perhaps?
- Structure of the cluster (1Co/1Da per server, all at the same place?)
-- 
Michael

As much as I heard, their benchmark in 2012 was not correct.   I had some talk with PGECons people and they made several correction on it.
---
Koichi Suzuki

2014/06/16 13:42、wormwang <wor...@ya...> のメール：

> Why the perf result of PostgreSQL decreased from 2084 to 910 at  2012 to 2013 at the Pgbench results?
> and Why the 4XCnode is much more than 4 times faster than 1 PostgreSQL?
> 
> -worm
> 
> On 2014/6/16 9:18, 鈴木 幸市 wrote:
>> Scalability result for DBT-1 will be found at https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability
>> which is linked from the main page of Postgres-XC Wiki, https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Main_Page
>> 
>> Pgbench result has been published at https://www.pgecons.org/wp-content/uploads/2014/pgecons2013png/wg1_scale-out.png
>> Sorry, it is in Japanese.
>> 
>> Regards;
>> ---
>> Koichi Suzuki
>> 
>> 2014/06/15 19:32、wormwang <wor...@ya...> のメール：
>> 
>>> Hi! guys
>>>   I want studying Postgres-XC v1.2 for new project. I
>>>   Where is the benchmark testing of Postgres-XC? I saw a old benchmark
>>> in Website, I can't find it now.
>>> 
>>> -worm
>>> 
>>> ------------------------------------------------------------------------------
>>> 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-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>> 
> 
> 

Why the perf result of PostgreSQL decreased from 2084 to 910 at  2012 to 
2013 at the Pgbench results?
and Why the 4XCnode is much more than 4 times faster than 1 PostgreSQL?

-worm

On 2014/6/16 9:18, 鈴木 幸市 wrote:
> Scalability result for DBT-1 will be found at https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability
> which is linked from the main page of Postgres-XC Wiki, https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Main_Page
>
> Pgbench result has been published at https://www.pgecons.org/wp-content/uploads/2014/pgecons2013png/wg1_scale-out.png
> Sorry, it is in Japanese.
>
> Regards;
> ---
> Koichi Suzuki
>
> 2014/06/15 19:32、wormwang <wor...@ya...> のメール：
>
>> Hi! guys
>>    I want studying Postgres-XC v1.2 for new project. I
>>    Where is the benchmark testing of Postgres-XC? I saw a old benchmark
>> in Website, I can't find it now.
>>
>> -worm
>>
>> ------------------------------------------------------------------------------
>> 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-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>

On Mon, Jun 16, 2014 at 10:18 AM, 鈴木 幸市 <ko...@in...> wrote:
> Pgbench result has been published at https://www.pgecons.org/wp-content/uploads/2014/pgecons2013png/wg1_scale-out.png
> Sorry, it is in Japanese.
Title: comparison 2012/2013

Up graph: read load
Down graph: write load
The rest can be guessed.
-- 
Michael

Scalability result for DBT-1 will be found at https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Scalability
which is linked from the main page of Postgres-XC Wiki, https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Main_Page

Pgbench result has been published at https://www.pgecons.org/wp-content/uploads/2014/pgecons2013png/wg1_scale-out.png
Sorry, it is in Japanese.

Regards;
---
Koichi Suzuki

2014/06/15 19:32、wormwang <wor...@ya...> のメール：

> Hi! guys
>   I want studying Postgres-XC v1.2 for new project. I
>   Where is the benchmark testing of Postgres-XC? I saw a old benchmark 
> in Website, I can't find it now.
> 
> -worm
> 
> ------------------------------------------------------------------------------
> 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-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 

Hi! guys
   I want studying Postgres-XC v1.2 for new project. I
   Where is the benchmark testing of Postgres-XC? I saw a old benchmark 
in Website, I can't find it now.

-worm

As Josh Berkus announced, there were bunch of XC-related discussions
in PGCon 2014. Whole meeting was very supportive to XC.

Materials will be found at following pages:
https://wiki.postgresql.org/wiki/PgCon2014ClusterSummit
https://wiki.postgresql.org/wiki/Pgcon2014PostgresXCmeeting

Also, there are a couple of unconference discussions related to XC.
Unconference page is
https://wiki.postgresql.org/wiki/Pgcon2014unconference

Hope these meeting notes are available soon.

Postgres-XC meeting was attended by several major PostgreSQL community
members as well as people interested in XC in their applications.

Through these discussions, I found the following are very important:

* XC has sufficient feature.   Stability is the crucial issue.
Priority of merge with PG9.4 is not high.  Missing features such as
WHERE CURRENT OF are not used.
* XC community should be more open.   For example, roadmap discussion
has not been done in public.
* Concentrate on simple benchmark, such as DBT-1, DBT-2 and pgbench.
* It is important to share evaluation and user experience.

I appreciate all the people in PGCon sessions/meetings for such
productive and fruitful discussions.

Give these suggestions, I'd like to begin open discussion of
Postgres-XC roadmap for release 1.3 and beyond, hopefully this
weekend.    Current core members are revising current roadmap to
reflect these discussions.   This will be published as a material for
discussions/proposals/comments/etc.

Any more input is very welcome.

Thank you very much.
---
Koichi Suzuki

This should happen.   After prepare succeeds, then each node (in this
case the native code from PG) guarantees that following commit must
succeed.   If not, 2PC protocol requires to correct this manually.
In this case 2PC protocol does not guarantee the transaction update
consistency.   This does not look XC's MVCC bug but what we need extra
work to correct this based on 2PC.

To correct this, you should visit each datanode and make correction.
You can use EXECUTE DIRECT for this purpose.   You can do this as a
superuser and by setting xc_maintenance_mode to on.

Regards;
---
Koichi Suzuki


2014-05-07 19:46 GMT+09:00 Wang Diancheng <dia...@gm...>:
> I wrote an extension 'xc2pctest' to debug and test internal 2PC in
> Postgres-XC, which need a small patch to master code. The patch and
> source of the extension attached.
>
> I add a hook at remote commit stage on coordinator when it do a 2PC
> commit, the extension xc2pctest will make one node fail to commit
> and the other node success, the whole cluster will go into partial
> commit state.
>
> following are reproduce steps for the MVCC bug:
>
> 1. patch the git master code using attached patch, recompile and
> reinstall the whole Postgres-XC, then compile and install
> the extension xc2pctest
>
> 2. create a cluster with 1 GTM, and 1 Coordinator named co1, and 2
> Datanodes named dn1 and dn2, and start it.
>
> 3. execute following SQL statement to create tables, load the extension
> and do some update to make cluster go into partial commit state:
>
> create table t1(a int, b int) to node (dn1);
> create table t2(a int, b int) to node (dn2);
> create extension xc2pctest;
> insert into t2 values(2,2);
> insert into t1 values(1,1);
> select install_xc2pctest_fail_hook();
> begin;
> update t1 set b = 11;
> update t2 set b = 22;
> commit;
> execute direct on (dn1) 'select * from pg_prepared_xact()';
> execute direct on (dn2) 'select * from pg_prepared_xact()';
>
> 4. the step 3, we created table 't1' on Datanode 'dn1', and table 't2'
> on Datanode 'dn2', and we *just inserted 1 row* for each table and
> updated them. The transaction of updtes will be failed due to the
> extension enabled. The last 2 statements in step 3 will tell us which
> node (which table) success to commit, it is the table 't1' on my machine.
>
> 5. now update the success updated table (it is 't1' in my test), and
> show the result, the output is following in my machine:
>
> postgres=# update t1 set b = 111 where a = 1;
> UPDATE 1
> postgres=# select xmin, xmax, * from t1;
>  xmin  | xmax  | a |  b
> -------+-------+---+-----
>  10018 | 10020 | 1 |   1
>  10096 | 10096 | 1 | 111
> (2 rows)
>
> 6. you can see 2 rows in step 5(there should be just 1 rows, and updates
> shoud be blocked under read committed isolation level).
>
> I think this is a serious MVCC bug in Postgres-XC.
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

The problem looks to need some careful review to dig into.   Please
allow me a bit more.

Regards;
---
Koichi Suzuki


2014-05-07 19:46 GMT+09:00 Wang Diancheng <dia...@gm...>:
> I wrote an extension 'xc2pctest' to debug and test internal 2PC in
> Postgres-XC, which need a small patch to master code. The patch and
> source of the extension attached.
>
> I add a hook at remote commit stage on coordinator when it do a 2PC
> commit, the extension xc2pctest will make one node fail to commit
> and the other node success, the whole cluster will go into partial
> commit state.
>
> following are reproduce steps for the MVCC bug:
>
> 1. patch the git master code using attached patch, recompile and
> reinstall the whole Postgres-XC, then compile and install
> the extension xc2pctest
>
> 2. create a cluster with 1 GTM, and 1 Coordinator named co1, and 2
> Datanodes named dn1 and dn2, and start it.
>
> 3. execute following SQL statement to create tables, load the extension
> and do some update to make cluster go into partial commit state:
>
> create table t1(a int, b int) to node (dn1);
> create table t2(a int, b int) to node (dn2);
> create extension xc2pctest;
> insert into t2 values(2,2);
> insert into t1 values(1,1);
> select install_xc2pctest_fail_hook();
> begin;
> update t1 set b = 11;
> update t2 set b = 22;
> commit;
> execute direct on (dn1) 'select * from pg_prepared_xact()';
> execute direct on (dn2) 'select * from pg_prepared_xact()';
>
> 4. the step 3, we created table 't1' on Datanode 'dn1', and table 't2'
> on Datanode 'dn2', and we *just inserted 1 row* for each table and
> updated them. The transaction of updtes will be failed due to the
> extension enabled. The last 2 statements in step 3 will tell us which
> node (which table) success to commit, it is the table 't1' on my machine.
>
> 5. now update the success updated table (it is 't1' in my test), and
> show the result, the output is following in my machine:
>
> postgres=# update t1 set b = 111 where a = 1;
> UPDATE 1
> postgres=# select xmin, xmax, * from t1;
>  xmin  | xmax  | a |  b
> -------+-------+---+-----
>  10018 | 10020 | 1 |   1
>  10096 | 10096 | 1 | 111
> (2 rows)
>
> 6. you can see 2 rows in step 5(there should be just 1 rows, and updates
> shoud be blocked under read committed isolation level).
>
> I think this is a serious MVCC bug in Postgres-XC.
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

I wrote an extension 'xc2pctest' to debug and test internal 2PC in
Postgres-XC, which need a small patch to master code. The patch and
source of the extension attached.

I add a hook at remote commit stage on coordinator when it do a 2PC
commit, the extension xc2pctest will make one node fail to commit
and the other node success, the whole cluster will go into partial
commit state.

following are reproduce steps for the MVCC bug:

1. patch the git master code using attached patch, recompile and
reinstall the whole Postgres-XC, then compile and install
the extension xc2pctest

2. create a cluster with 1 GTM, and 1 Coordinator named co1, and 2
Datanodes named dn1 and dn2, and start it.

3. execute following SQL statement to create tables, load the extension
and do some update to make cluster go into partial commit state:

create table t1(a int, b int) to node (dn1);
create table t2(a int, b int) to node (dn2);
create extension xc2pctest;
insert into t2 values(2,2);
insert into t1 values(1,1);
select install_xc2pctest_fail_hook();
begin;
update t1 set b = 11;
update t2 set b = 22;
commit;
execute direct on (dn1) 'select * from pg_prepared_xact()';
execute direct on (dn2) 'select * from pg_prepared_xact()';

4. the step 3, we created table 't1' on Datanode 'dn1', and table 't2'
on Datanode 'dn2', and we *just inserted 1 row* for each table and
updated them. The transaction of updtes will be failed due to the
extension enabled. The last 2 statements in step 3 will tell us which
node (which table) success to commit, it is the table 't1' on my machine.

5. now update the success updated table (it is 't1' in my test), and
show the result, the output is following in my machine:

postgres=# update t1 set b = 111 where a = 1;
UPDATE 1
postgres=# select xmin, xmax, * from t1;
 xmin  | xmax  | a |  b  
-------+-------+---+-----
 10018 | 10020 | 1 |   1
 10096 | 10096 | 1 | 111
(2 rows)

6. you can see 2 rows in step 5(there should be just 1 rows, and updates
shoud be blocked under read committed isolation level).

I think this is a serious MVCC bug in Postgres-XC.

Okay, I understood.   The first hunk removes a sentence which does not make any sense.

Thanks.
---
Koichi Suzuki

2014/04/24 11:46、Masataka Saito <pg...@gm...> のメール：

> On 24 April 2014 11:04, 鈴木 幸市 <ko...@in...> wrote:
>> Thanks a lot Wang;
>> 
>> The first patch may not be effective because handle does not propagate to caller.
>> 
> 
> The variable handle does not propagate to caller.
> Therefore, the first hunk is reasonable.
> 
> Regards.
> 
>> The second one looks reasonable.
>> 
>> Regards;
>> ---
>> Koichi Suzuki
>> 
>> 2014/04/23 22:13、Wang Diancheng <dia...@gm...> のメール：
>> 
>>> Hi,
>>> 
>>> patch attached.
>>> 
>>> diff --git a/src/backend/pgxc/pool/poolmgr.c b/src/backend/pgxc/pool/poolmgr.c
>>> index 02ed656..432fb85 100644
>>> --- a/src/backend/pgxc/pool/poolmgr.c
>>> +++ b/src/backend/pgxc/pool/poolmgr.c
>>> @@ -389,7 +389,6 @@ PoolManagerCloseHandle(PoolHandle *handle)
>>> {
>>>      close(Socket(handle->port));
>>>      free(handle);
>>> -     handle = NULL;
>>> }
>>> 
>>> 
>>> @@ -818,7 +817,7 @@ PoolManagerDisconnect(void)
>>>      pool_putmessage(&poolHandle->port, 'd', NULL, 0);
>>>      pool_flush(&poolHandle->port);
>>> 
>>> -     close(Socket(poolHandle->port));
>>> +     PoolManagerCloseHandle(poolHandle);
>>>      poolHandle = NULL;
>>> }
>>> 
>>> ------------------------------------------------------------------------------
>>> Start Your Social Network Today - Download eXo Platform
>>> Build your Enterprise Intranet with eXo Platform Software
>>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>>> http://p.sf.net/sfu/ExoPlatform_______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> 
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 

On 24 April 2014 11:04, 鈴木 幸市 <ko...@in...> wrote:
> Thanks a lot Wang;
>
> The first patch may not be effective because handle does not propagate to caller.
>

The variable handle does not propagate to caller.
Therefore, the first hunk is reasonable.

Regards.

> The second one looks reasonable.
>
> Regards;
> ---
> Koichi Suzuki
>
> 2014/04/23 22:13、Wang Diancheng <dia...@gm...> のメール：
>
>> Hi,
>>
>> patch attached.
>>
>> diff --git a/src/backend/pgxc/pool/poolmgr.c b/src/backend/pgxc/pool/poolmgr.c
>> index 02ed656..432fb85 100644
>> --- a/src/backend/pgxc/pool/poolmgr.c
>> +++ b/src/backend/pgxc/pool/poolmgr.c
>> @@ -389,7 +389,6 @@ PoolManagerCloseHandle(PoolHandle *handle)
>> {
>>       close(Socket(handle->port));
>>       free(handle);
>> -     handle = NULL;
>> }
>>
>>
>> @@ -818,7 +817,7 @@ PoolManagerDisconnect(void)
>>       pool_putmessage(&poolHandle->port, 'd', NULL, 0);
>>       pool_flush(&poolHandle->port);
>>
>> -     close(Socket(poolHandle->port));
>> +     PoolManagerCloseHandle(poolHandle);
>>       poolHandle = NULL;
>> }
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform_______________________________________________
>> Postgres-xc-developers mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Thanks a lot Wang;

The first patch may not be effective because handle does not propagate to caller.

The second one looks reasonable.

Regards;
---
Koichi Suzuki

2014/04/23 22:13、Wang Diancheng <dia...@gm...> のメール：

> Hi,
> 
> patch attached.
> 
> diff --git a/src/backend/pgxc/pool/poolmgr.c b/src/backend/pgxc/pool/poolmgr.c
> index 02ed656..432fb85 100644
> --- a/src/backend/pgxc/pool/poolmgr.c
> +++ b/src/backend/pgxc/pool/poolmgr.c
> @@ -389,7 +389,6 @@ PoolManagerCloseHandle(PoolHandle *handle)
> {
> 	close(Socket(handle->port));
> 	free(handle);
> -	handle = NULL;
> }
> 
> 
> @@ -818,7 +817,7 @@ PoolManagerDisconnect(void)
> 	pool_putmessage(&poolHandle->port, 'd', NULL, 0);
> 	pool_flush(&poolHandle->port);
> 
> -	close(Socket(poolHandle->port));
> +	PoolManagerCloseHandle(poolHandle);
> 	poolHandle = NULL;
> }
> 
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Thanks Wang for the patch.   At a glance, it looks nice.   Please let me take a closer look before commit.

Regards;
---
Koichi Suzuki

2014/04/23 22:17、Wang Diancheng <dia...@gm...> のメール：

> Hi,
> 
> patch attached.
> 
> 
> diff --git a/src/backend/access/transam/gtm.c b/src/backend/access/transam/gtm.c
> index 943ce57..087313e 100644
> --- a/src/backend/access/transam/gtm.c
> +++ b/src/backend/access/transam/gtm.c
> @@ -170,12 +170,13 @@ BeginTranAutovacuumGTM(void)
> int
> CommitTranGTM(GlobalTransactionId gxid)
> {
> -	int ret;
> +	int ret = -1;
> 
> 	if (!GlobalTransactionIdIsValid(gxid))
> 		return 0;
> 	CheckConnection();
> -	ret = commit_transaction(conn, gxid);
> +	if (conn)
> +		ret = commit_transaction(conn, gxid);
> 
> 	/*
> 	 * If something went wrong (timeout), try and reset GTM connection.
> @@ -203,12 +204,13 @@ CommitTranGTM(GlobalTransactionId gxid)
> int
> CommitPreparedTranGTM(GlobalTransactionId gxid, GlobalTransactionId prepared_gxid)
> {
> -	int ret = 0;
> +	int ret = -1;
> 
> 	if (!GlobalTransactionIdIsValid(gxid) || !GlobalTransactionIdIsValid(prepared_gxid))
> -		return ret;
> +		return 0;
> 	CheckConnection();
> -	ret = commit_prepared_transaction(conn, gxid, prepared_gxid);
> +	if (conn)
> +		ret = commit_prepared_transaction(conn, gxid, prepared_gxid);
> 
> 	/*
> 	 * If something went wrong (timeout), try and reset GTM connection.
> @@ -257,13 +259,13 @@ StartPreparedTranGTM(GlobalTransactionId gxid,
> 					 char *gid,
> 					 char *nodestring)
> {
> -	int ret = 0;
> +	int ret = -1;
> 
> 	if (!GlobalTransactionIdIsValid(gxid))
> 		return 0;
> 	CheckConnection();
> -
> -	ret = start_prepared_transaction(conn, gxid, gid, nodestring);
> +	if (conn)
> +		ret = start_prepared_transaction(conn, gxid, gid, nodestring);
> 
> 	/*
> 	 * If something went wrong (timeout), try and reset GTM connection.
> @@ -282,12 +284,13 @@ StartPreparedTranGTM(GlobalTransactionId gxid,
> int
> PrepareTranGTM(GlobalTransactionId gxid)
> {
> -	int ret;
> +	int ret = -1;
> 
> 	if (!GlobalTransactionIdIsValid(gxid))
> 		return 0;
> 	CheckConnection();
> -	ret = prepare_transaction(conn, gxid);
> +	if (conn)
> +		ret = prepare_transaction(conn, gxid);
> 
> 	/*
> 	 * If something went wrong (timeout), try and reset GTM connection.
> @@ -310,11 +313,12 @@ GetGIDDataGTM(char *gid,
> 			  GlobalTransactionId *prepared_gxid,
> 			  char **nodestring)
> {
> -	int ret = 0;
> +	int ret = -1;
> 
> 	CheckConnection();
> -	ret = get_gid_data(conn, GTM_ISOLATION_RC, gid, gxid,
> -					   prepared_gxid, nodestring);
> +	if (conn)
> +		ret = get_gid_data(conn, GTM_ISOLATION_RC, gid, gxid,
> +						   prepared_gxid, nodestring);
> 
> 	/*
> 	 * If something went wrong (timeout), try and reset GTM connection.
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers