postgres-xc-general Mailing List for Postgres-XC

Safer way is to use EXECUTE DIRECT.   It is physically possible to
connect psql to datanode directly but because transactions are not
controlled by GTM in this case, you cannot guarantee the visibility
and the data integrity.

Regards;
----------
Koichi Suzuki


2012/6/30 Aris Setyawan <ari...@gm...>:
> Hi,
>
> I have use a case that need to (manually using gearman) split a
> postgre recursive query to a numbers of replication node, to execute
> it faster.
>
> Since I will use postgre-xc cluster, is it possible to connect a
> (postgresql) data node server (a relpica in my case above) directly
> (not using coordiantor)?
>
> thank's.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

Hi,

I have use a case that need to (manually using gearman) split a
postgre recursive query to a numbers of replication node, to execute
it faster.

Since I will use postgre-xc cluster, is it possible to connect a
(postgresql) data node server (a relpica in my case above) directly
(not using coordiantor)?

thank's.

Thanks to all for the tips, all up and running now !

PS , on the short version of documentation, it does not mentioned the HOST parameter:

http://postgres-xc.sourceforge.net/docs/1_0/install-short.html

Though I am guessing it all works fine when installed on the same machine

Thanks again

Neil
________________________________________
From: Michael Paquier [mic...@gm...]
Sent: Monday, June 25, 2012 2:09 AM
To: Neil Mooney
Cc: pos...@li...
Subject: Re: [Postgres-xc-general] createdb: database creation failed: ERROR: Failed to get pooled connections

On Mon, Jun 25, 2012 at 10:07 AM, Michael Paquier <mic...@gm...<mailto:mic...@gm...>> wrote:
I may be stepping someone's else answer... But here is some input.

On Fri, Jun 22, 2012 at 9:30 PM, Neil Mooney <nm...@xu...<mailto:nm...@xu...>> wrote:
Can anyone point out where I am going wrong here ?

Here is a complete log of what i've done to setup , error at the end:

Data/Coordinator machines:
==========================

node1:
======

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_coordinator1
mkdir -p /opt/postgres/data_datanode1

chown postgres: /opt/postgres/data_*

su - postgres

initdb -D /opt/postgres/data_coordinator1 --nodename coordinator1
initdb -D /opt/postgres/data_datanode1 --nodename datanode1

#configure /opt/postgres/data_coordinator1/postgres.conf with GTM server
#configure /opt/postgres/data_datanode1/postgres.conf with GTM server


postgres -X -p 15432 -D /opt/postgres/data_datanode1 >>logfile 2>&1 &
postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &

node2:
======

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_coordinator2
mkdir -p /opt/postgres/data_datanode2

chown postgres: /opt/postgres/data_*

su - postgres

initdb -D /opt/postgres/data_coordinator2 --nodename coordinator2
initdb -D /opt/postgres/data_datanode2 --nodename datanode2

#configure /opt/postgres/data_coordinator2/postgres.conf with GTM server
#configure /opt/postgres/data_datanode2/postgres.conf with GTM server

postgres -X -p 15433 -D /opt/postgres/data_datanode2 >>logfile 2>&1 &
postgres -C -D /opt/postgres/data_coordinator2 >>logfile 2>&1 &

each coordinator node:
======================

postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
You already started your nodes at an earlier step, so this is not necessary.
An error would be returned telling that node is already started like postgres.
GTM machine:
=============

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_gtm

chown postgres: /opt/postgres/data*

su - postgres

initgtm -D /opt/postgres/data_gtm -Z gtm
gtm -D /opt/postgres/data_gtm >logfile 2>&1 &
You should start GTM before starting your 2 Coordinators and your 2 Datanodes.
Postgres-XC nodes need to register on GTM at start-up or they cannot start.


Registering Nodes: (all datanodes ??? has been done on both, output below)
==================

psql -c "CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432)" postgres
psql -c "CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433)" postgres
psql -c "SELECT pgxc_pool_reload()" postgres
select oid,node_name from pgxc_node;

Here you have to launch CREATE NODE and pgxc_pool_reload on each Coordinator. When you start up a node this node knows only about itself, so you need to register all the other Coordinators and Datanodes. Registering other Coordinators on a Coordinator is mandatory or you won't be able to synchronize DDL among Coordinators, this could result in a table being created on a Coordinator and not another.

So, in your case, launch the following queries:
- On Coordinator 1:
CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST = '$node1_ip');
CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST = '$node2_ip');
CREATE NODE coordinator2 WITH (TYPE = 'coordinator', PORT = 5432, HOST = '$node2_ip');
- On Coordinator 2:
CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST = '$node1_ip');
CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST = '$node2_ip');
CREATE NODE coordinator1 WITH (TYPE = 'coordinator', PORT = 5432, HOST = '$node2_ip');
There is a mistake here. On Coordinator 2, coordinator1 should be registered with a host set to $node1_ip, resulting in:
CREATE NODE coordinator1 WITH (TYPE = 'coordinator', PORT = 5432, HOST = '$node1_ip');
--
Michael Paquier
http://michael.otacoo.com

On Mon, Jun 25, 2012 at 10:07 AM, Michael Paquier <mic...@gm...
> wrote:

> I may be stepping someone's else answer... But here is some input.
>
> On Fri, Jun 22, 2012 at 9:30 PM, Neil Mooney <nm...@xu...> wrote:
>
>> Can anyone point out where I am going wrong here ?
>>
>> Here is a complete log of what i've done to setup , error at the end:
>>
>> Data/Coordinator machines:
>> ==========================
>>
>> node1:
>> ======
>>
>> rm -fr /opt/postgres/data*
>>
>> mkdir -p /opt/postgres/data_coordinator1
>> mkdir -p /opt/postgres/data_datanode1
>>
>> chown postgres: /opt/postgres/data_*
>>
>> su - postgres
>>
>> initdb -D /opt/postgres/data_coordinator1 --nodename coordinator1
>> initdb -D /opt/postgres/data_datanode1 --nodename datanode1
>>
>> #configure /opt/postgres/data_coordinator1/postgres.conf with GTM server
>> #configure /opt/postgres/data_datanode1/postgres.conf with GTM server
>>
>>
>> postgres -X -p 15432 -D /opt/postgres/data_datanode1 >>logfile 2>&1 &
>> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>>
>> node2:
>> ======
>>
>> rm -fr /opt/postgres/data*
>>
>> mkdir -p /opt/postgres/data_coordinator2
>> mkdir -p /opt/postgres/data_datanode2
>>
>> chown postgres: /opt/postgres/data_*
>>
>> su - postgres
>>
>> initdb -D /opt/postgres/data_coordinator2 --nodename coordinator2
>> initdb -D /opt/postgres/data_datanode2 --nodename datanode2
>>
>> #configure /opt/postgres/data_coordinator2/postgres.conf with GTM server
>> #configure /opt/postgres/data_datanode2/postgres.conf with GTM server
>>
>> postgres -X -p 15433 -D /opt/postgres/data_datanode2 >>logfile 2>&1 &
>> postgres -C -D /opt/postgres/data_coordinator2 >>logfile 2>&1 &
>>
>> each coordinator node:
>> ======================
>>
>> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>>
> You already started your nodes at an earlier step, so this is not
> necessary.
> An error would be returned telling that node is already started like
> postgres.
>
>> GTM machine:
>> =============
>>
>> rm -fr /opt/postgres/data*
>>
>> mkdir -p /opt/postgres/data_gtm
>>
>> chown postgres: /opt/postgres/data*
>>
>> su - postgres
>>
>> initgtm -D /opt/postgres/data_gtm -Z gtm
>> gtm -D /opt/postgres/data_gtm >logfile 2>&1 &
>>
> You should start GTM *before* starting your 2 Coordinators and your 2
> Datanodes.
> Postgres-XC nodes need to register on GTM at start-up or they cannot start.
>
>
>>
>> Registering Nodes: (all datanodes ??? has been done on both, output below)
>> ==================
>>
>> psql -c "CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432)"
>> postgres
>> psql -c "CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433)"
>> postgres
>> psql -c "SELECT pgxc_pool_reload()" postgres
>> select oid,node_name from pgxc_node;
>>
>
> Here you have to launch CREATE NODE and pgxc_pool_reload on *each
> Coordinator*. When you start up a node this node knows only about itself,
> so you need to register all the other Coordinators and Datanodes.
> Registering other Coordinators on a Coordinator is mandatory or you won't
> be able to synchronize DDL among Coordinators, this could result in a table
> being created on a Coordinator and not another.
>
> So, in your case, launch the following queries:
> - On Coordinator 1:
> CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST =
> '$node1_ip');
> CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST =
> '$node2_ip');
> CREATE NODE coordinator2 WITH (TYPE = 'coordinator', PORT = 5432, HOST =
> '$node2_ip');
> - On Coordinator 2:
> CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST =
> '$node1_ip');
> CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST =
> '$node2_ip');
> CREATE NODE coordinator1 WITH (TYPE = 'coordinator', PORT = 5432, HOST =
> '$node2_ip');
>
There is a mistake here. On Coordinator 2, coordinator1 should be
registered with a host set to $node1_ip, resulting in:
CREATE NODE coordinator1 WITH (TYPE = 'coordinator', PORT = 5432, HOST =
'$node1_ip');
-- 
Michael Paquier
http://michael.otacoo.com

I may be stepping someone's else answer... But here is some input.

On Fri, Jun 22, 2012 at 9:30 PM, Neil Mooney <nm...@xu...> wrote:

> Can anyone point out where I am going wrong here ?
>
> Here is a complete log of what i've done to setup , error at the end:
>
> Data/Coordinator machines:
> ==========================
>
> node1:
> ======
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_coordinator1
> mkdir -p /opt/postgres/data_datanode1
>
> chown postgres: /opt/postgres/data_*
>
> su - postgres
>
> initdb -D /opt/postgres/data_coordinator1 --nodename coordinator1
> initdb -D /opt/postgres/data_datanode1 --nodename datanode1
>
> #configure /opt/postgres/data_coordinator1/postgres.conf with GTM server
> #configure /opt/postgres/data_datanode1/postgres.conf with GTM server
>
>
> postgres -X -p 15432 -D /opt/postgres/data_datanode1 >>logfile 2>&1 &
> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>
> node2:
> ======
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_coordinator2
> mkdir -p /opt/postgres/data_datanode2
>
> chown postgres: /opt/postgres/data_*
>
> su - postgres
>
> initdb -D /opt/postgres/data_coordinator2 --nodename coordinator2
> initdb -D /opt/postgres/data_datanode2 --nodename datanode2
>
> #configure /opt/postgres/data_coordinator2/postgres.conf with GTM server
> #configure /opt/postgres/data_datanode2/postgres.conf with GTM server
>
> postgres -X -p 15433 -D /opt/postgres/data_datanode2 >>logfile 2>&1 &
> postgres -C -D /opt/postgres/data_coordinator2 >>logfile 2>&1 &
>
> each coordinator node:
> ======================
>
> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>
You already started your nodes at an earlier step, so this is not necessary.
An error would be returned telling that node is already started like
postgres.

> GTM machine:
> =============
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_gtm
>
> chown postgres: /opt/postgres/data*
>
> su - postgres
>
> initgtm -D /opt/postgres/data_gtm -Z gtm
> gtm -D /opt/postgres/data_gtm >logfile 2>&1 &
>
You should start GTM *before* starting your 2 Coordinators and your 2
Datanodes.
Postgres-XC nodes need to register on GTM at start-up or they cannot start.


>
> Registering Nodes: (all datanodes ??? has been done on both, output below)
> ==================
>
> psql -c "CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432)"
> postgres
> psql -c "CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433)"
> postgres
> psql -c "SELECT pgxc_pool_reload()" postgres
> select oid,node_name from pgxc_node;
>

Here you have to launch CREATE NODE and pgxc_pool_reload on *each
Coordinator*. When you start up a node this node knows only about itself,
so you need to register all the other Coordinators and Datanodes.
Registering other Coordinators on a Coordinator is mandatory or you won't
be able to synchronize DDL among Coordinators, this could result in a table
being created on a Coordinator and not another.

So, in your case, launch the following queries:
- On Coordinator 1:
CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST =
'$node1_ip');
CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST =
'$node2_ip');
CREATE NODE coordinator2 WITH (TYPE = 'coordinator', PORT = 5432, HOST =
'$node2_ip');
- On Coordinator 2:
CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432, HOST =
'$node1_ip');
CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433, HOST =
'$node2_ip');
CREATE NODE coordinator1 WITH (TYPE = 'coordinator', PORT = 5432, HOST =
'$node2_ip');

In the case of node1, datanode1 and coordinator1 are on the same node. So
you can replace $node1_ip with localhost or 127.0.0.1 when defining
datanode1 for coordinator1.
Same for node node2, datanode2 and coordinator2 are on the same node. So
you can replace $node2_ip with localhost or 127.0.0.1 when defining
datanode2 for coordinator2.



> #output
>
> node1:
> postgres=# select oid,node_name from pgxc_node;
>  oid  |  node_name
> -------+--------------
>  11129 | coordinator1
>  16384 | datanode1
>  16385 | datanode2
> (3 rows)
>
This output is incorrect.
Coordinator 1 is not aware of Coordinator 2. Coordinator 1 also thinks that
datanode2 is on node1 as you did not define an IP to redirect correctly.


>
>
> node2:
> [postgres@las1-app015 ~]$ psql -c "select oid,node_name from pgxc_node;"
> postgres
>  oid  |  node_name
> -------+--------------
>  11129 | coordinator2
>  16384 | datanode1
>  16385 | datanode2
> (3 rows)
>
Same here, Coordinator 1 is not aware of Coordinator2.
Coordinator2 thinks that datanode1 is on the same server, which is not the
case as it looks that coordinator2/datanode2 and coordinator1/datanode1 are
grouped on 2 different nodes.

>
> Creating DB's :
> ===============
>
> [postgres@las1-app014 ~]$ createdb test
> createdb: database creation failed: ERROR:  Failed to get pooled
> connections
>

Here I guess you are connecting to coordinator1.
This error happens because coordinator1 cannot connect to datanode2, as it
is not located on local server but on server node2.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com

I just spotted another mistake in data node creation. You are creating both
the data nodes on both the coordinators with the default IP i.e. 127.0.0.1
which is not true for datanode1 when created on coordinator2. Similarly it
is not true for datanode2 on coordinator1. It would be good idea to create
both data nodes by explicitly specifying the IP addresses.

So the queries should look something like this.

psql -c "CREATE NODE datanode1 WITH (HOST = 'IP_OF_datanode1', TYPE =
'datanode', PORT = 15432)" postgres
psql -c "CREATE NODE datanode2 WITH (HOST = 'IP_OF_datanode2', TYPE =
'datanode', PORT = 15433)" postgres
psql -c "CREATE NODE coordinator1 WITH (HOST = '10.152.14.24', type =
'coordinator', PORT = 5432);" postgres
psql -c "CREATE NODE coordinator2 WITH (HOST = '10.152.14.25', type =
'coordinator', PORT = 5432);" postgres

If this does not work and gives the same error please provide the output of

psql -c "select oid,* from pgxc_node;" postgres

by running on the coordinator2.

On Fri, Jun 22, 2012 at 7:06 PM, Neil Mooney <nm...@xu...> wrote:

> Thanks to Magorn and Abbass for their input.
>
> I followed your advice RE: creating new coordinator nodes in the db with
> the following query on both nodes:
>
> psql -c "DROP NODE coordinator1" postgres
> psql -c "DROP NODE coordinator2" postgres
> psql -c "CREATE NODE coordinator1 WITH (HOST = '10.152.14.24', type =
> 'coordinator', PORT = 5432);" postgres
> psql -c "CREATE NODE coordinator2 WITH (HOST = '10.152.14.25', type =
> 'coordinator', PORT = 5432);" postgres
> psql -c "SELECT pgxc_pool_reload()" postgres
>
> I am still seeing a problem, logfile indicates connectivity between the
> two data nodes, telnet-ing the port seems to work ok.
>
> [postgres@las1-app015 ~]$ cat logfile
>
> LOG:  database system was interrupted; last known up at 2012-06-22
> 13:31:58 UTC
> LOG:  database system was not properly shut down; automatic recovery in
> progress
> LOG:  record with zero length at 0/1776A90
> LOG:  redo is not required
> LOG:  autovacuum launcher started
> LOG:  database system is ready to accept connections
> LOG:  database system was interrupted; last known up at 2012-06-22
> 13:32:20 UTC
> LOG:  database system was not properly shut down; automatic recovery in
> progress
> LOG:  redo starts at 0/177F970
> LOG:  record with zero length at 0/177FB60
> LOG:  redo done at 0/177FB20
> LOG:  last completed transaction was at log time 2012-06-22
> 13:34:59.977913+00
> LOG:  autovacuum launcher started
> LOG:  database system is ready to accept connections
> LOG:  incomplete startup packet
> LOG:  incomplete startup packet
> LOG:  failed to connect to Datanode
> WARNING:  can not connect to node 16384
> LOG:  failed to acquire connections
> STATEMENT:  CREATE DATABASE test;
>
> ERROR:  Failed to get pooled connections
> STATEMENT:  CREATE DATABASE test;
>
> [postgres@las1-app015 ~]$ psql -c "select oid,node_name from pgxc_node;"
> postgres
>  oid  |  node_name
> -------+--------------
>  11129 | coordinator2
>  16384 | datanode1
>  16385 | datanode2
>  24583 | coordinator1
> (4 rows)
>
> [postgres@las1-app015 ~]$ telnet las1-app014 15432
> Trying 10.152.14.24...
> Connected to las1-app014.
> Escape character is '^]'.
> ^]
>
> telnet> quit
> Connection closed.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Thanks to Magorn and Abbass for their input.

I followed your advice RE: creating new coordinator nodes in the db with the following query on both nodes:

psql -c "DROP NODE coordinator1" postgres
psql -c "DROP NODE coordinator2" postgres
psql -c "CREATE NODE coordinator1 WITH (HOST = '10.152.14.24', type = 'coordinator', PORT = 5432);" postgres
psql -c "CREATE NODE coordinator2 WITH (HOST = '10.152.14.25', type = 'coordinator', PORT = 5432);" postgres
psql -c "SELECT pgxc_pool_reload()" postgres

I am still seeing a problem, logfile indicates connectivity between the two data nodes, telnet-ing the port seems to work ok.

[postgres@las1-app015 ~]$ cat logfile 

LOG:  database system was interrupted; last known up at 2012-06-22 13:31:58 UTC
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/1776A90
LOG:  redo is not required
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections
LOG:  database system was interrupted; last known up at 2012-06-22 13:32:20 UTC
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 0/177F970
LOG:  record with zero length at 0/177FB60
LOG:  redo done at 0/177FB20
LOG:  last completed transaction was at log time 2012-06-22 13:34:59.977913+00
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections
LOG:  incomplete startup packet
LOG:  incomplete startup packet
LOG:  failed to connect to Datanode
WARNING:  can not connect to node 16384
LOG:  failed to acquire connections
STATEMENT:  CREATE DATABASE test;

ERROR:  Failed to get pooled connections
STATEMENT:  CREATE DATABASE test;

[postgres@las1-app015 ~]$ psql -c "select oid,node_name from pgxc_node;" postgres
  oid  |  node_name   
-------+--------------
 11129 | coordinator2
 16384 | datanode1
 16385 | datanode2
 24583 | coordinator1
(4 rows)

[postgres@las1-app015 ~]$ telnet las1-app014 15432
Trying 10.152.14.24...
Connected to las1-app014.
Escape character is '^]'.
^]

telnet> quit
Connection closed.

You have 2 data nodes and 2 coordinators in the cluster. In this case you
need to create coordinator1 on coordinator2 and coordinator2 on
coordinator1. You need to add some thing similar to these queries when
creating nodes on each of the coordinators.

On coordinator1
CREATE NODE coordinator2 WITH (HOST = 'IP_OF_coordinator2_HERE', type =
'coordinator', PORT = 5432);

and On coordinator2
CREATE NODE coordinator1 WITH (HOST = 'IP_OF_coordinator1_HERE', type =
'coordinator', PORT = 5432);

Thanks.

On Fri, Jun 22, 2012 at 5:30 PM, Neil Mooney <nm...@xu...> wrote:

> Can anyone point out where I am going wrong here ?
>
> Here is a complete log of what i've done to setup , error at the end:
>
> Data/Coordinator machines:
> ==========================
>
> node1:
> ======
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_coordinator1
> mkdir -p /opt/postgres/data_datanode1
>
> chown postgres: /opt/postgres/data_*
>
> su - postgres
>
> initdb -D /opt/postgres/data_coordinator1 --nodename coordinator1
> initdb -D /opt/postgres/data_datanode1 --nodename datanode1
>
> #configure /opt/postgres/data_coordinator1/postgres.conf with GTM server
> #configure /opt/postgres/data_datanode1/postgres.conf with GTM server
>
>
> postgres -X -p 15432 -D /opt/postgres/data_datanode1 >>logfile 2>&1 &
> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>
> node2:
> ======
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_coordinator2
> mkdir -p /opt/postgres/data_datanode2
>
> chown postgres: /opt/postgres/data_*
>
> su - postgres
>
> initdb -D /opt/postgres/data_coordinator2 --nodename coordinator2
> initdb -D /opt/postgres/data_datanode2 --nodename datanode2
>
> #configure /opt/postgres/data_coordinator2/postgres.conf with GTM server
> #configure /opt/postgres/data_datanode2/postgres.conf with GTM server
>
> postgres -X -p 15433 -D /opt/postgres/data_datanode2 >>logfile 2>&1 &
> postgres -C -D /opt/postgres/data_coordinator2 >>logfile 2>&1 &
>
> each coordinator node:
> ======================
>
> postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &
>
>
> tail -f log
>
> GTM machine:
> =============
>
> rm -fr /opt/postgres/data*
>
> mkdir -p /opt/postgres/data_gtm
>
> chown postgres: /opt/postgres/data*
>
> su - postgres
>
> initgtm -D /opt/postgres/data_gtm -Z gtm
> gtm -D /opt/postgres/data_gtm >logfile 2>&1 &
>
> Registering Nodes: (all datanodes ??? has been done on both, output below)
> ==================
>
> psql -c "CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432)"
> postgres
> psql -c "CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433)"
> postgres
> psql -c "SELECT pgxc_pool_reload()" postgres
> select oid,node_name from pgxc_node;
>
> #output
>
> node1:
> postgres=# select oid,node_name from pgxc_node;
>  oid  |  node_name
> -------+--------------
>  11129 | coordinator1
>  16384 | datanode1
>  16385 | datanode2
> (3 rows)
>
>
> node2:
> [postgres@las1-app015 ~]$ psql -c "select oid,node_name from pgxc_node;"
> postgres
>  oid  |  node_name
> -------+--------------
>  11129 | coordinator2
>  16384 | datanode1
>  16385 | datanode2
> (3 rows)
>
>
>
>
> Creating DB's :
> ===============
>
> [postgres@las1-app014 ~]$ createdb test
> createdb: database creation failed: ERROR:  Failed to get pooled
> connections
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
--
Abbas
Architect
EnterpriseDB Corporation
The Enterprise PostgreSQL Company

Phone: 92-334-5100153

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.

Can anyone point out where I am going wrong here ?

Here is a complete log of what i've done to setup , error at the end:

Data/Coordinator machines:
==========================

node1:
======

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_coordinator1
mkdir -p /opt/postgres/data_datanode1

chown postgres: /opt/postgres/data_*

su - postgres

initdb -D /opt/postgres/data_coordinator1 --nodename coordinator1
initdb -D /opt/postgres/data_datanode1 --nodename datanode1

#configure /opt/postgres/data_coordinator1/postgres.conf with GTM server
#configure /opt/postgres/data_datanode1/postgres.conf with GTM server


postgres -X -p 15432 -D /opt/postgres/data_datanode1 >>logfile 2>&1 &
postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &

node2:
======

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_coordinator2
mkdir -p /opt/postgres/data_datanode2

chown postgres: /opt/postgres/data_*

su - postgres

initdb -D /opt/postgres/data_coordinator2 --nodename coordinator2
initdb -D /opt/postgres/data_datanode2 --nodename datanode2

#configure /opt/postgres/data_coordinator2/postgres.conf with GTM server
#configure /opt/postgres/data_datanode2/postgres.conf with GTM server

postgres -X -p 15433 -D /opt/postgres/data_datanode2 >>logfile 2>&1 &
postgres -C -D /opt/postgres/data_coordinator2 >>logfile 2>&1 &

each coordinator node:
======================

postgres -C -D /opt/postgres/data_coordinator1 >>logfile 2>&1 &


tail -f log	

GTM machine:
=============

rm -fr /opt/postgres/data*

mkdir -p /opt/postgres/data_gtm

chown postgres: /opt/postgres/data*

su - postgres

initgtm -D /opt/postgres/data_gtm -Z gtm
gtm -D /opt/postgres/data_gtm >logfile 2>&1 &

Registering Nodes: (all datanodes ??? has been done on both, output below)
==================

psql -c "CREATE NODE datanode1 WITH (TYPE = 'datanode', PORT = 15432)" postgres
psql -c "CREATE NODE datanode2 WITH (TYPE = 'datanode', PORT = 15433)" postgres
psql -c "SELECT pgxc_pool_reload()" postgres
select oid,node_name from pgxc_node;

#output 

node1:
postgres=# select oid,node_name from pgxc_node;
  oid  |  node_name   
-------+--------------
 11129 | coordinator1
 16384 | datanode1
 16385 | datanode2
(3 rows)


node2:
[postgres@las1-app015 ~]$ psql -c "select oid,node_name from pgxc_node;" postgres
  oid  |  node_name   
-------+--------------
 11129 | coordinator2
 16384 | datanode1
 16385 | datanode2
(3 rows)




Creating DB's :
===============

[postgres@las1-app014 ~]$ createdb test
createdb: database creation failed: ERROR:  Failed to get pooled connections

XC speaks the same wire level protocol as PostgreSQL, so all drivers and connectors should in theory work.


Sent from my IPhone

On Jun 11, 2012, at 8:13 AM, Fernando Lozano <fer...@lo...> wrote:

> Hi Michael,
> 
> Found the offending text. It's in the README from many releases, including 1.0.0:
> 
> Postgres-XC is aiming to provide transparent access to the database, which means one can use existing PostgreSQL application as is. For implementation reason,
> ***transparency level is limited to access via libpq libraries***
> and simple statements as found in the Architecture Document in the release material.
> 
> PHP, Perl and most users won't be bothered because those language drivers use libpq, but Java developers use a pure-java JDBC driver which does not uses libpq at all.
> 
> This statement on the README may be understood as "there are changes to libpq in postgresql-xc so you have to use our libpq. Other clients won't work".
> 
> But as I understand you reply, I can use any libpq to access postgresql-xc without problem. For example, a pgAdminIII binary for windows that I already use for a plain PostgreSQL server should work out-of-the-box with PostgreSQL-XC, or the rpm files from Debian Linux for a PHP app. And I could also use other clients, not based on libpq, such as a JDBC driver anda a .Net provider, right?
> 
> 
> []s, Fernando Lozano
> 
>> Hi,
>> 
>> I spent half an hour browsing the website, wiki and docs and could not find where I read that postgresql-xc should be transparent to libpq clients. Will keep looking later.
>> 
>> 
>> []s, Fernando Lozano
>> 
>> 
>>> Hi,
>>> 
>>> You should avoid sending responses to Postgres announce mailing lists people are going to complain. Better to use the MLs dedicated to xc.
>>> Please find my answers below.
>>> 
>>> On 2012/06/09, at 1:54, Fernando Lozano <fer...@lo...> wrote:
>>> 
>>>> Hi Michael,
>>>> 
>>>> Very interesting, but the docs states that it is "transparent" only for libpq clients. This means Java                 clients (using the type 4 JDBC driver) can't use PostgreSQL XC?
>>> Documentation is wrong. We tested with many drivers like php, ruby, perl, jdbc, ecpg, etc.
>>> And the only problems we saw was with odbc because it uses returning and ctid. The rest was working well.
>>> Could you indicate in which page the error is located?
>>>> 
>>>> Also, as far as I understand the docs, I need something external do implement failover if I connect to a database server which comes offline (JBoss AS HA Datasources comes to mind), and there's no balancer included. Am I right?
>>> Yes you are right. There is a kind of load balancing between Datanodes and Coordinators by design thanks to the distributed nature of tables and the possibility to control read for replicated tables on specific nodes. However it might be preferable to have load balancing from something external.
>>> 
>>> Regards,
>>> 
>>> Michael
>>>> 
>>>> 
>>>> []s, Fernando Lozano
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Postgres-XC, read&write-scalable multi-master symmetric cluster based on PostgreSQL, version 1.0.0 is released.
>>>>> This project is seen as an open-source alternative to costly products such as OracleRAC. Postgres-XC is based on the code of PostgreSQL, so it can naturally use all its technologies, which are enhaunced to have a shared-nothing multi-master PostgreSQL-based database cluster.
>>>>> 
>>>>> This first stable version is based on PostgreSQL 9.1.4. All the patches in PostgreSQL 9.1 stable branch have been merged up to commit 873d1c1 (1st of June 2012).
>>>>> This includes the security fix related to pg_crypto dated of 30th of May.
>>>>> You can download the source tarball directly from here:
>>>>> https://sourceforge.net/projects/postgres-xc/files/latest/download
>>>>> This tarball contains all the HTML and man documentation.
>>>>> 
>>>>> 30 bug fixes have been made since release of beta2, with some notable enhancements:
>>>>> - Support for EXTENSION is fixed
>>>>> - Stabilization of the use of slave nodes in cluster
>>>>> - Fix of a bug related to read-only transactions, improving performance by 15%.
>>>>> - Support of compilation for MacOSX
>>>>> About the scalability of this release, Postgres-XC 1.0.0 scales to a factor of 3 when compared to a standalone server PostgreSQL 9.1.3 on 5 nodes using a benchmark called DBT-1.
>>>>> 
>>>>> Compared to version Postgres-XC 0.9.7, the following features have been added:
>>>>> - Fast query shipping (FQS), quick identification of expressions in a query that can be pushed down to remote nodes
>>>>> - SERIAL types
>>>>> - TABLESPACE
>>>>> - Utility to clean up 2PC transactions in cluster (pgxc_clean)
>>>>> - Utility for initialization of GTM (global transaction manager, utility called initgtm)
>>>>> - Relation-size functions and locking functions
>>>>> - Regression stabilization
>>>>> 
>>>>> The documentation of 1.0, including release notes, is available here:
>>>>> http://postgres-xc.sourceforge.net/docs/1_0/.
>>>>> 
>>>>> The project can be followed on Source Forge: http://postgres-xc.sourceforge.net/.
>>>>> And a couple of GIT repositories are used for development:
>>>>> - SourceForge: http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=summary
>>>>> - Github: https://github.com/postgres-xc/postgres-xc
>>>>> 
>>>>> The core team is currently working in the addition of new features for the next major release including:
>>>>> - Merge with PostgreSQL 9.2
>>>>> - Data redistribution functionality, changing table distribution in cluster with a simple ALTER TABLE
>>>>> - New functionalities related to online node addition and deletion for a better user experience
>>>>> - Triggers
>>>>> - Planner improvements
>>>>> - Global constraints.
>>>>> The roadmap of the project is located here => http://postgres-xc.sourceforge.net/ in section Roadmap.
>>>>> 
>>>>> The project is under the same license as PostgreSQL, now managed under a single entity called "Postgres-XC Development Group".
>>>>> In order to keep in touch with the project, whose development follows the same model as PostgreSQL, you can register to the following mailing lists:
>>>>> - pos...@li..., for general questions. Registration can be done here: https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>> - pos...@li.... hachers mailing list. Registration can be done here: https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> 
>>>>> See you soon on the project mailing list, and have fun with this stable release.
>>>>> -- 
>>>>> Michael Paquier
>>>>> Member of core team of Postgres-XC, and Postgres-XC Development Group
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

On Mon, Jun 11, 2012 at 9:13 PM, Fernando Lozano <fer...@lo...>wrote:

>  Hi Michael,
>
> Found the offending text. It's in the README from many releases, including
> 1.0.0:
>
> Postgres-XC is aiming to provide transparent access to the database, which
> means one can use existing PostgreSQL application as is. For implementation
> reason,
> ***transparency level is limited to access via libpq libraries***
> and simple statements as found in the Architecture Document in the release
> material.
>
> PHP, Perl and most users won't be bothered because those language drivers
> use libpq, but Java developers use a pure-java JDBC driver which does not
> uses libpq at all.
>
> This statement on the README may be understood as "there are changes to
> libpq in postgresql-xc so you have to use our libpq. Other clients won't
> work".
>
The point is that we haven't changed libpq at all. It is exactly the same
as vanilla postgres.


>
> But as I understand you reply, I can use any libpq to access postgresql-xc
> without problem. For example, a pgAdminIII binary for windows that I
> already use for a plain PostgreSQL server should work out-of-the-box with
> PostgreSQL-XC, or the rpm files from Debian Linux for a PHP app. And I
> could also use other clients, not based on libpq, such as a JDBC driver
> anda a .Net provider, right?
>
Yes everything should work.
I played a couple of months ago and pgadmin was working correctly by
connecting to Coordinator.
Other drivers also should work normally. If they do not work, well it is a
bug. As I told before there are only limitations with odbc, because it uses
ctid and in XC ctid is not unique among nodes.

Btw, I found that the incorrect file is in the README of each version
folder in SourceForge.
Thanks for pointing that out. I'll upload a modified version.
-- 
Michael Paquier
http://michael.otacoo.com

Hi Michael,

Found the offending text. It's in the README from many releases, 
including 1.0.0:

Postgres-XC is aiming to provide transparent access to the database, 
which means one can use existing PostgreSQL application as is. For 
implementation reason,
***transparency level is limited to access via libpq libraries***
and simple statements as found in the Architecture Document in the 
release material.

PHP, Perl and most users won't be bothered because those language 
drivers use libpq, but Java developers use a pure-java JDBC driver which 
does not uses libpq at all.

This statement on the README may be understood as "there are changes to 
libpq in postgresql-xc so you have to use our libpq. Other clients won't 
work".

But as I understand you reply, I can use any libpq to access 
postgresql-xc without problem. For example, a pgAdminIII binary for 
windows that I already use for a plain PostgreSQL server should work 
out-of-the-box with PostgreSQL-XC, or the rpm files from Debian Linux 
for a PHP app. And I could also use other clients, not based on libpq, 
such as a JDBC driver anda a .Net provider, right?


[]s, Fernando Lozano

> Hi,
>
> I spent half an hour browsing the website, wiki and docs and could not 
> find where I read that postgresql-xc should be transparent to libpq 
> clients. Will keep looking later.
>
>
> []s, Fernando Lozano
>
>
>> Hi,
>>
>> You should avoid sending responses to Postgres announce mailing lists 
>> people are going to complain. Better to use the MLs dedicated to xc.
>> Please find my answers below.
>>
>> On 2012/06/09, at 1:54, Fernando Lozano <fer...@lo... 
>> <mailto:fer...@lo...>> wrote:
>>
>>> Hi Michael,
>>>
>>> Very interesting, but the docs states that it is "transparent" only 
>>> for libpq clients. This means Java clients (using the type 4 JDBC 
>>> driver) can't use PostgreSQL XC?
>> Documentation is wrong. We tested with many drivers like php, ruby, 
>> perl, jdbc, ecpg, etc.
>> And the only problems we saw was with odbc because it uses returning 
>> and ctid. The rest was working well.
>> Could you indicate in which page the error is located?
>>>
>>> Also, as far as I understand the docs, I need something external do 
>>> implement failover if I connect to a database server which comes 
>>> offline (JBoss AS HA Datasources comes to mind), and there's no 
>>> balancer included. Am I right?
>> Yes you are right. There is a kind of load balancing between 
>> Datanodes and Coordinators by design thanks to the distributed nature 
>> of tables and the possibility to control read for replicated tables 
>> on specific nodes. However it might be preferable to have load 
>> balancing from something external.
>>
>> Regards,
>>
>> Michael
>>>
>>>
>>> []s, Fernando Lozano
>>>
>>>> Hi all,
>>>>
>>>> Postgres-XC, read&write-scalable multi-master symmetric cluster 
>>>> based on PostgreSQL, version 1.0.0 is released.
>>>> This project is seen as an open-source alternative to costly 
>>>> products such as OracleRAC. Postgres-XC is based on the code of 
>>>> PostgreSQL, so it can naturally use all its technologies, which are 
>>>> enhaunced to have a shared-nothing multi-master PostgreSQL-based 
>>>> database cluster.
>>>>
>>>> This first stable version is based on PostgreSQL 9.1.4. All the 
>>>> patches in PostgreSQL 9.1 stable branch have been merged up to 
>>>> commit 873d1c1 (1st of June 2012).
>>>> This includes the security fix related to pg_crypto dated of 30th 
>>>> of May.
>>>> You can download the source tarball directly from here:
>>>> https://sourceforge.net/projects/postgres-xc/files/latest/download
>>>> This tarball contains all the HTML and man documentation.
>>>>
>>>> 30 bug fixes have been made since release of beta2, with some 
>>>> notable enhancements:
>>>> - Support for EXTENSION is fixed
>>>> - Stabilization of the use of slave nodes in cluster
>>>> - Fix of a bug related to read-only transactions, improving 
>>>> performance by 15%.
>>>> - Support of compilation for MacOSX
>>>> About the scalability of this release, Postgres-XC 1.0.0 scales to 
>>>> a factor of 3 when compared to a standalone server PostgreSQL 9.1.3 
>>>> on 5 nodes using a benchmark called DBT-1.
>>>>
>>>> Compared to version Postgres-XC 0.9.7, the following features have 
>>>> been added:
>>>> - Fast query shipping (FQS), quick identification of expressions in 
>>>> a query that can be pushed down to remote nodes
>>>> - SERIAL types
>>>> - TABLESPACE
>>>> - Utility to clean up 2PC transactions in cluster (pgxc_clean)
>>>> - Utility for initialization of GTM (global transaction manager, 
>>>> utility called initgtm)
>>>> - Relation-size functions and locking functions
>>>> - Regression stabilization
>>>>
>>>> The documentation of 1.0, including release notes, is available here:
>>>> http://postgres-xc.sourceforge.net/docs/1_0/.
>>>>
>>>> The project can be followed on Source Forge: 
>>>> http://postgres-xc.sourceforge.net/.
>>>> And a couple of GIT repositories are used for development:
>>>> - SourceForge: 
>>>> http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=summary
>>>> - Github: https://github.com/postgres-xc/postgres-xc
>>>>
>>>> The core team is currently working in the addition of new features 
>>>> for the next major release including:
>>>> - Merge with PostgreSQL 9.2
>>>> - Data redistribution functionality, changing table distribution in 
>>>> cluster with a simple ALTER TABLE
>>>> - New functionalities related to online node addition and deletion 
>>>> for a better user experience
>>>> - Triggers
>>>> - Planner improvements
>>>> - Global constraints.
>>>> The roadmap of the project is located here => 
>>>> http://postgres-xc.sourceforge.net/ in section Roadmap.
>>>>
>>>> The project is under the same license as PostgreSQL, now managed 
>>>> under a single entity called "Postgres-XC Development Group".
>>>> In order to keep in touch with the project, whose development 
>>>> follows the same model as PostgreSQL, you can register to the 
>>>> following mailing lists:
>>>> - pos...@li... 
>>>> <mailto:pos...@li...>, for general 
>>>> questions. Registration can be done here: 
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>> - pos...@li... 
>>>> <mailto:pos...@li...>. hachers 
>>>> mailing list. Registration can be done here: 
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>
>>>> See you soon on the project mailing list, and have fun with this 
>>>> stable release.
>>>> -- 
>>>> Michael Paquier
>>>> Member of core team of Postgres-XC, and Postgres-XC Development Group
>>>
>>>
>
>

On Mon, Jun 11, 2012 at 9:02 PM, Fernando Lozano <fer...@lo...>wrote:

>  Hi,
>
> I spent half an hour browsing the website, wiki and docs and could not
> find where I read that postgresql-xc should be transparent to libpq
> clients. Will keep looking later.
>
Thanks.
Please keep me updated if you find anything. Improving documentation is a
nerver-ending task
Regards,


>
>
> []s, Fernando Lozano
>
>
>   Hi,
>
>  You should avoid sending responses to Postgres announce mailing lists
> people are going to complain. Better to use the MLs dedicated to xc.
> Please find my answers below.
>
>  On 2012/06/09, at 1:54, Fernando Lozano <fer...@lo...> wrote:
>
>   Hi Michael,
>
> Very interesting, but the docs states that it is "transparent" only for
> libpq clients. This means Java clients (using the type 4 JDBC driver) can't
> use PostgreSQL XC?
>
> Documentation is wrong. We tested with many drivers like php, ruby, perl,
> jdbc, ecpg, etc.
> And the only problems we saw was with odbc because it uses returning and
> ctid. The rest was working well.
> Could you indicate in which page the error is located?
>
>
> Also, as far as I understand the docs, I need something external do
> implement failover if I connect to a database server which comes offline
> (JBoss AS HA Datasources comes to mind), and there's no balancer included.
> Am I right?
>
> Yes you are right. There is a kind of load balancing between Datanodes and
> Coordinators by design thanks to the distributed nature of tables and the
> possibility to control read for replicated tables on specific nodes.
> However it might be preferable to have load balancing from something
> external.
>
>  Regards,
>
>  Michael
>
>
>
> []s, Fernando Lozano
>
>  Hi all,
>
> Postgres-XC, read&write-scalable multi-master symmetric cluster based on
> PostgreSQL, version 1.0.0 is released.
> This project is seen as an open-source alternative to costly products such
> as OracleRAC. Postgres-XC is based on the code of PostgreSQL, so it can
> naturally use all its technologies, which are enhaunced to have a
> shared-nothing multi-master PostgreSQL-based database cluster.
>
> This first stable version is based on PostgreSQL 9.1.4. All the patches in
> PostgreSQL 9.1 stable branch have been merged up to commit 873d1c1 (1st of
> June 2012).
> This includes the security fix related to pg_crypto dated of 30th of May.
> You can download the source tarball directly from here:
> https://sourceforge.net/projects/postgres-xc/files/latest/download
> This tarball contains all the HTML and man documentation.
>
> 30 bug fixes have been made since release of beta2, with some notable
> enhancements:
> - Support for EXTENSION is fixed
> - Stabilization of the use of slave nodes in cluster
> - Fix of a bug related to read-only transactions, improving performance by
> 15%.
> - Support of compilation for MacOSX
> About the scalability of this release, Postgres-XC 1.0.0 scales to a
> factor of 3 when compared to a standalone server PostgreSQL 9.1.3 on 5
> nodes using a benchmark called DBT-1.
>
> Compared to version Postgres-XC 0.9.7, the following features have been
> added:
> - Fast query shipping (FQS), quick identification of expressions in a
> query that can be pushed down to remote nodes
> - SERIAL types
> - TABLESPACE
> - Utility to clean up 2PC transactions in cluster (pgxc_clean)
> - Utility for initialization of GTM (global transaction manager, utility
> called initgtm)
> - Relation-size functions and locking functions
> - Regression stabilization
>
> The documentation of 1.0, including release notes, is available here:
> http://postgres-xc.sourceforge.net/docs/1_0/.
>
> The project can be followed on Source Forge:
> http://postgres-xc.sourceforge.net/.
> And a couple of GIT repositories are used for development:
> - SourceForge:
> http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=summary
> - Github: https://github.com/postgres-xc/postgres-xc
>
> The core team is currently working in the addition of new features for the
> next major release including:
> - Merge with PostgreSQL 9.2
> - Data redistribution functionality, changing table distribution in
> cluster with a simple ALTER TABLE
> - New functionalities related to online node addition and deletion for a
> better user experience
> - Triggers
> - Planner improvements
> - Global constraints.
> The roadmap of the project is located here =>
> http://postgres-xc.sourceforge.net/ in section Roadmap.
>
> The project is under the same license as PostgreSQL, now managed under a
> single entity called "Postgres-XC Development Group".
> In order to keep in touch with the project, whose development follows the
> same model as PostgreSQL, you can register to the following mailing lists:
> - pos...@li..., for general questions.
> Registration can be done here:
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> - pos...@li.... hachers mailing list.
> Registration can be done here:
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
> See you soon on the project mailing list, and have fun with this stable
> release.
> --
> Michael Paquier
> Member of core team of Postgres-XC, and Postgres-XC Development Group
>
>
>
>
>
>


-- 
Michael Paquier
http://michael.otacoo.com

Hi,

I spent half an hour browsing the website, wiki and docs and could not 
find where I read that postgresql-xc should be transparent to libpq 
clients. Will keep looking later.


[]s, Fernando Lozano


> Hi,
>
> You should avoid sending responses to Postgres announce mailing lists 
> people are going to complain. Better to use the MLs dedicated to xc.
> Please find my answers below.
>
> On 2012/06/09, at 1:54, Fernando Lozano <fer...@lo... 
> <mailto:fer...@lo...>> wrote:
>
>> Hi Michael,
>>
>> Very interesting, but the docs states that it is "transparent" only 
>> for libpq clients. This means Java clients (using the type 4 JDBC 
>> driver) can't use PostgreSQL XC?
> Documentation is wrong. We tested with many drivers like php, ruby, 
> perl, jdbc, ecpg, etc.
> And the only problems we saw was with odbc because it uses returning 
> and ctid. The rest was working well.
> Could you indicate in which page the error is located?
>>
>> Also, as far as I understand the docs, I need something external do 
>> implement failover if I connect to a database server which comes 
>> offline (JBoss AS HA Datasources comes to mind), and there's no 
>> balancer included. Am I right?
> Yes you are right. There is a kind of load balancing between Datanodes 
> and Coordinators by design thanks to the distributed nature of tables 
> and the possibility to control read for replicated tables on specific 
> nodes. However it might be preferable to have load balancing from 
> something external.
>
> Regards,
>
> Michael
>>
>>
>> []s, Fernando Lozano
>>
>>> Hi all,
>>>
>>> Postgres-XC, read&write-scalable multi-master symmetric cluster 
>>> based on PostgreSQL, version 1.0.0 is released.
>>> This project is seen as an open-source alternative to costly 
>>> products such as OracleRAC. Postgres-XC is based on the code of 
>>> PostgreSQL, so it can naturally use all its technologies, which are 
>>> enhaunced to have a shared-nothing multi-master PostgreSQL-based 
>>> database cluster.
>>>
>>> This first stable version is based on PostgreSQL 9.1.4. All the 
>>> patches in PostgreSQL 9.1 stable branch have been merged up to 
>>> commit 873d1c1 (1st of June 2012).
>>> This includes the security fix related to pg_crypto dated of 30th of 
>>> May.
>>> You can download the source tarball directly from here:
>>> https://sourceforge.net/projects/postgres-xc/files/latest/download
>>> This tarball contains all the HTML and man documentation.
>>>
>>> 30 bug fixes have been made since release of beta2, with some 
>>> notable enhancements:
>>> - Support for EXTENSION is fixed
>>> - Stabilization of the use of slave nodes in cluster
>>> - Fix of a bug related to read-only transactions, improving 
>>> performance by 15%.
>>> - Support of compilation for MacOSX
>>> About the scalability of this release, Postgres-XC 1.0.0 scales to a 
>>> factor of 3 when compared to a standalone server PostgreSQL 9.1.3 on 
>>> 5 nodes using a benchmark called DBT-1.
>>>
>>> Compared to version Postgres-XC 0.9.7, the following features have 
>>> been added:
>>> - Fast query shipping (FQS), quick identification of expressions in 
>>> a query that can be pushed down to remote nodes
>>> - SERIAL types
>>> - TABLESPACE
>>> - Utility to clean up 2PC transactions in cluster (pgxc_clean)
>>> - Utility for initialization of GTM (global transaction manager, 
>>> utility called initgtm)
>>> - Relation-size functions and locking functions
>>> - Regression stabilization
>>>
>>> The documentation of 1.0, including release notes, is available here:
>>> http://postgres-xc.sourceforge.net/docs/1_0/.
>>>
>>> The project can be followed on Source Forge: 
>>> http://postgres-xc.sourceforge.net/.
>>> And a couple of GIT repositories are used for development:
>>> - SourceForge: 
>>> http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=summary
>>> - Github: https://github.com/postgres-xc/postgres-xc
>>>
>>> The core team is currently working in the addition of new features 
>>> for the next major release including:
>>> - Merge with PostgreSQL 9.2
>>> - Data redistribution functionality, changing table distribution in 
>>> cluster with a simple ALTER TABLE
>>> - New functionalities related to online node addition and deletion 
>>> for a better user experience
>>> - Triggers
>>> - Planner improvements
>>> - Global constraints.
>>> The roadmap of the project is located here => 
>>> http://postgres-xc.sourceforge.net/ in section Roadmap.
>>>
>>> The project is under the same license as PostgreSQL, now managed 
>>> under a single entity called "Postgres-XC Development Group".
>>> In order to keep in touch with the project, whose development 
>>> follows the same model as PostgreSQL, you can register to the 
>>> following mailing lists:
>>> - pos...@li... 
>>> <mailto:pos...@li...>, for general 
>>> questions. Registration can be done here: 
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>> - pos...@li... 
>>> <mailto:pos...@li...>. hachers 
>>> mailing list. Registration can be done here: 
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>> See you soon on the project mailing list, and have fun with this 
>>> stable release.
>>> -- 
>>> Michael Paquier
>>> Member of core team of Postgres-XC, and Postgres-XC Development Group
>>
>>

Hmmm... It's more interesting.
---
Koichi

On Sat, 9 Jun 2012 13:08:01 -0400
Mason <ma...@us...> wrote:

> On Sat, Jun 9, 2012 at 5:40 AM, Michael Paquier
> <mic...@gm...> wrote:
> > Hi,
> >
> > I found an article while browsing the web comparing pgpool-ii, XC and
> > postgres. OK, that's mostly pgpool but the latest paragraph is what caught
> > my attention.
> > It would be nice to get in touch with this guy, it doesn't look that he
> > heard about the latest news of the project: release of 1.0.
> > http://www.varnernet.com/~bryan/2012/05/29/i-love-postgresql-but-pgpool-ii-is-another-story/
> >
> > At least the comment on pgpool-ii is kind of... interesting.
> > I let see it yourself.
> >
> > Someone knows who this guy is?
> 
> I replied about a week ago, but he either deleted my response or is
> moderating comments.
> 
> Mason
> 
> > --
> > Michael Paquier
> > http://michael.otacoo.com
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Postgres-xc-general mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> >
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> 

On Sat, Jun 9, 2012 at 5:40 AM, Michael Paquier
<mic...@gm...> wrote:
> Hi,
>
> I found an article while browsing the web comparing pgpool-ii, XC and
> postgres. OK, that's mostly pgpool but the latest paragraph is what caught
> my attention.
> It would be nice to get in touch with this guy, it doesn't look that he
> heard about the latest news of the project: release of 1.0.
> http://www.varnernet.com/~bryan/2012/05/29/i-love-postgresql-but-pgpool-ii-is-another-story/
>
> At least the comment on pgpool-ii is kind of... interesting.
> I let see it yourself.
>
> Someone knows who this guy is?

I replied about a week ago, but he either deleted my response or is
moderating comments.

Mason

> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>

Hi,

I found an article while browsing the web comparing pgpool-ii, XC and
postgres. OK, that's mostly pgpool but the latest paragraph is what caught
my attention.
It would be nice to get in touch with this guy, it doesn't look that he
heard about the latest news of the project: release of 1.0.
http://www.varnernet.com/~bryan/2012/05/29/i-love-postgresql-but-pgpool-ii-is-another-story/

At least the comment on pgpool-ii is kind of... interesting.
I let see it yourself.

Someone knows who this guy is?
-- 
Michael Paquier
http://michael.otacoo.com

On Sat, Jun 9, 2012 at 10:29 AM, Michael Vitale <mic...@ar...> wrote:

> Thanks for the responses.  I'd like to pursue the jdbc driver issue for
> Postgres-xc a bit more...
>
> Regarding the jdbc driver for Postgresql, it would be neat if we could
> take a current cut of the postgresql jdbc driver and customize it for
> postgres-xc, so that the input connection string could contain an array of
> coordinator addresses, just like oracleRAC, so we could have "automatic
> failover" at the coordinator node level embedded right into the jdbc
> driver.  Consider new jdbc pseudo code:
>

I think jdbc driver has already some failover functionalities already
included in it, but honestly not sure.
So it might be that there is already some code in that would help to
support multiple connections to cluster nodes.
However I am not really updated on the development so perhaps such a
feature is not implemented, but I am sure that JDBC guys might be
interested in such a feature to redirect read-only queries to slave nodes
for example just for vanilla postgres.

Btw, the functionality you propose would be helpful for both projects.
You should have a look here to get in touch with the latest development:
http://github.com/pgjdbc/pgjdbc.


>
> If sql connect error encountered, see if the connection string contains
> another coordinator address and if so, connect to that coordinator and set
> its handle globally to replace the original connection handle so other
> threads will use it as well for future IO requests to the database.
>
> Now of course this doesn't handle failover at the data node level, but is
> seems like it would sure do the trick at the coordinator node level.
>
Yes that would be helpful. But be sure to check if there is not already
some infrastructure in jdbc itself.

Even if automatic failover on Datanodes is a core feature, there are
already some ways to check if a Datanode is alive or not from a
Coordinator, so you could also know when a Datanode is down and promote a
slave attached to it.
There is a functionality called EXECUTE DIRECT whose doc is here:
http://postgres-xc.sourceforge.net/docs/1_0/sql-executedirect.html
This SQL specific to XC allows to launch a query directly to a remote node,
Coordinator or Datanode when connected on a Coordinator.

For example, let's imagine that your driver is connected to Coordinator
called node_coord1, and you have Datanodes called node_dn1, node_dn2, ...
node_dnN.
You can simply check if the node (here node_dn2) is alive by launching
something like:
EXECUTE DIRECT ON NODE node_dn2 'SELECT 1';
If the node is offline for a reason or another pooler will complain telling
that it cannot get a connection to remote node.

You can also use that from a Coordinator to check if a remote Coordinator
is down.


>
> Now let me compare this new postgres-xc jdbc driver to HA failover already
> embedded in JBOSS AS 7.  It would be much better, because while JBOSS would
> allow you to input multiple jdbc connection strings (using the vertical bar
> separator), it does not break down bad connections and automatically
> reconnect those clients to the other one.  Instead it will just make sure
> that future connection handle requests are directed to the other one.
>  Already connected users would have to manually logoff from their
> applications and log on again.  But if we embed multiple coordinators into
> a new Postgres-xc jdbc driver, then the driver will break down the bad
> connections and automatically connect those users to the other cordinators
> without the users having to do anything!
>
> Although I'm calling this a new jdbc driver for postgres-xc, the concept
> would work the same for postgresql and postgres-xc: jdbc driver allows
> specification of multiple database connection parameters.
>
> What you all think?  And if you all know where this would be useful to a
> postgresql jdbc community email address, please forward this.
>
So it would be nice.
Your module should be pluggable on top of jdbc, or even directly included
in jdbc if you consider the case of normal postgreSQL with master and slave
nodes (slave nodes are read-only) for read-query balancing.
-- 
Michael Paquier
http://michael.otacoo.com

We have discussed this issue inside some of the core members.   Your
proposal looks very nice to XC.    I'm interested in how this can be
maintained in a long run.    Do you have any idea?

Regards;
----------
Koichi Suzuki


2012/6/9 Michael Vitale <mic...@ar...>:
> Thanks for the responses.  I'd like to pursue the jdbc driver issue for Postgres-xc a bit more...
>
> Regarding the jdbc driver for Postgresql, it would be neat if we could take a current cut of the postgresql jdbc driver and customize it for postgres-xc, so that the input connection string could contain an array of coordinator addresses, just like oracleRAC, so we could have "automatic failover" at the coordinator node level embedded right into the jdbc driver.  Consider new jdbc pseudo code:
>
> If sql connect error encountered, see if the connection string contains another coordinator address and if so, connect to that coordinator and set its handle globally to replace the original connection handle so other threads will use it as well for future IO requests to the database.
>
> Now of course this doesnt handle failover at the data node level, but is seems like it would sure do the trick at the coordinator node level.
>
> Now let me compare this new postgres-xc jdbc driver to HA failover already embedded in JBOSS AS 7.  It would be much better, because while JBOSS would allow you to input multiple jdbc connection strings (using the vertical bar separator), it does not break down bad connections and automatically reconnect those clients to the other one.  Instead it will just make sure that future connection handle requests are directed to the other one.  Already connected users would have to manually logoff from their applications and log on again.  But if we embed multiple coordinators into a new Postgres-xc jdbc driver, then the driver will break down the bad connections and automatically connect those users to the other cordinators without the users having to do anything!
>
> Although I'm calling this a new jdbc driver for postgres-xc, the concept would work the same for postgresql and postgres-xc: jdbc driver allows specification of multiple database connection parameters.
>
> What you all think?  And if you all know where this would be useful to a postgresql jdbc community email address, please forward this.
>
> Respectfully Yours,
> Michael Vitale
>
> ________________________________________
> From: Michael Paquier [mic...@gm...]
> Sent: Friday, June 08, 2012 8:30 AM
> To: Michael Vitale
> Cc: Postgres-XC mailing list
> Subject: Re: [Postgres-xc-general] An article about XC at PgCon
>
> On 2012/06/08, at 20:19, Michael Vitale <mic...@ar...> wrote:
>
>> How do you undo an initdb?  In the case where I want to redefine the initdb differently.  Also, I did the gmake uninstall, but it didn't remove any binary installed files.
> Let's take the problems one-by-one.
> For initdb, you need to delete the data folder and then recreate it. I don't think Postgres can redefine a data folder with initdb and just returns an error telling that existing data folder is not empty.
> gmaje uninstall should work. At least in the environments used here it does.
>>
>> Also, does postgres-xc work well as a High Availability solution, i.e., automatic failover?
> You will need to plug in yourself slave nodes to your master nodes and having  a monitoring engine that performs failover. You got the same problems with Postgres. Its core features cannot perform a failover themselves and you always need to kick something to perform a failover in case of a node failure.
>>
>> I come from an oracle RAC world, and I am playing with postgres-xc 1.0.0 on 2 centos 6, 64 bit boxes.
>>
>> Oracle has failover embedded in its listener configuration and in its jdbc driver.  For instance, the oracle jdbc driver for our jboss server is something like this:
>>
>> <connection-url>jdbc:oracle:thin:@(description=(address_list=(load_balance=on)(failover=off)(address=(protocol=tcp)(host=odb0-vip.arin.net)(port=1521))(address=(protocol=tcp)(host=odb1-vip.arin.net)(port=1521)))(connect_data=(service_name=pjpn.arin.net)(failover_mode=(type=select)(method=basic))))</connection-url>
>>
>> Note that 2 oracle nodes are specified right within the oracle jdbc driver.  For normal PostgreSQL, the driver would look something like this:
>> <connection-url>jdbc:postgresql://dbproto1.arin.net:5432/pjpn</connection-url>
>>
>> So, I'm wondering if there is already a way to specify more than one cordinator in the jdbc connection string for connecting to postgres-xc?
> I am not a specialist of jdbc, but I don't think you can specify multiple connection points in.
>>
>> If not, then I reckon its up to me to implement a vip switched node that would automatically point to another cordinator if the first vip went down.
> Yep think so. The core features of xc should be sufficient for a correct failover.
>>
>> Comments, suggestions?
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

Thanks for the responses.  I'd like to pursue the jdbc driver issue for Postgres-xc a bit more...

Regarding the jdbc driver for Postgresql, it would be neat if we could take a current cut of the postgresql jdbc driver and customize it for postgres-xc, so that the input connection string could contain an array of coordinator addresses, just like oracleRAC, so we could have "automatic failover" at the coordinator node level embedded right into the jdbc driver.  Consider new jdbc pseudo code:

If sql connect error encountered, see if the connection string contains another coordinator address and if so, connect to that coordinator and set its handle globally to replace the original connection handle so other threads will use it as well for future IO requests to the database.

Now of course this doesnt handle failover at the data node level, but is seems like it would sure do the trick at the coordinator node level.

Now let me compare this new postgres-xc jdbc driver to HA failover already embedded in JBOSS AS 7.  It would be much better, because while JBOSS would allow you to input multiple jdbc connection strings (using the vertical bar separator), it does not break down bad connections and automatically reconnect those clients to the other one.  Instead it will just make sure that future connection handle requests are directed to the other one.  Already connected users would have to manually logoff from their applications and log on again.  But if we embed multiple coordinators into a new Postgres-xc jdbc driver, then the driver will break down the bad connections and automatically connect those users to the other cordinators without the users having to do anything!

Although I'm calling this a new jdbc driver for postgres-xc, the concept would work the same for postgresql and postgres-xc: jdbc driver allows specification of multiple database connection parameters.

What you all think?  And if you all know where this would be useful to a postgresql jdbc community email address, please forward this.

Respectfully Yours,
Michael Vitale

________________________________________
From: Michael Paquier [mic...@gm...]
Sent: Friday, June 08, 2012 8:30 AM
To: Michael Vitale
Cc: Postgres-XC mailing list
Subject: Re: [Postgres-xc-general] An article about XC at PgCon

On 2012/06/08, at 20:19, Michael Vitale <mic...@ar...> wrote:

> How do you undo an initdb?  In the case where I want to redefine the initdb differently.  Also, I did the gmake uninstall, but it didn't remove any binary installed files.
Let's take the problems one-by-one.
For initdb, you need to delete the data folder and then recreate it. I don't think Postgres can redefine a data folder with initdb and just returns an error telling that existing data folder is not empty.
gmaje uninstall should work. At least in the environments used here it does.
>
> Also, does postgres-xc work well as a High Availability solution, i.e., automatic failover?
You will need to plug in yourself slave nodes to your master nodes and having  a monitoring engine that performs failover. You got the same problems with Postgres. Its core features cannot perform a failover themselves and you always need to kick something to perform a failover in case of a node failure.
>
> I come from an oracle RAC world, and I am playing with postgres-xc 1.0.0 on 2 centos 6, 64 bit boxes.
>
> Oracle has failover embedded in its listener configuration and in its jdbc driver.  For instance, the oracle jdbc driver for our jboss server is something like this:
>
> <connection-url>jdbc:oracle:thin:@(description=(address_list=(load_balance=on)(failover=off)(address=(protocol=tcp)(host=odb0-vip.arin.net)(port=1521))(address=(protocol=tcp)(host=odb1-vip.arin.net)(port=1521)))(connect_data=(service_name=pjpn.arin.net)(failover_mode=(type=select)(method=basic))))</connection-url>
>
> Note that 2 oracle nodes are specified right within the oracle jdbc driver.  For normal PostgreSQL, the driver would look something like this:
> <connection-url>jdbc:postgresql://dbproto1.arin.net:5432/pjpn</connection-url>
>
> So, I'm wondering if there is already a way to specify more than one cordinator in the jdbc connection string for connecting to postgres-xc?
I am not a specialist of jdbc, but I don't think you can specify multiple connection points in.
>
> If not, then I reckon its up to me to implement a vip switched node that would automatically point to another cordinator if the first vip went down.
Yep think so. The core features of xc should be sufficient for a correct failover.
>
> Comments, suggestions?
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

Hi,

You should avoid sending responses to Postgres announce mailing lists people are going to complain. Better to use the MLs dedicated to xc.
Please find my answers below.

On 2012/06/09, at 1:54, Fernando Lozano <fer...@lo...> wrote:

> Hi Michael,
> 
> Very interesting, but the docs states that it is "transparent" only for libpq clients. This means Java clients (using the type 4 JDBC driver) can't use PostgreSQL XC?
Documentation is wrong. We tested with many drivers like php, ruby, perl, jdbc, ecpg, etc.
And the only problems we saw was with odbc because it uses returning and ctid. The rest was working well.
Could you indicate in which page the error is located?
> 
> Also, as far as I understand the docs, I need something external do implement failover if I connect to a database server which comes offline (JBoss AS HA Datasources comes to mind), and there's no balancer included. Am I right?
Yes you are right. There is a kind of load balancing between Datanodes and Coordinators by design thanks to the distributed nature of tables and the possibility to control read for replicated tables on specific nodes. However it might be preferable to have load balancing from something external.

Regards,

Michael
> 
> 
> []s, Fernando Lozano
> 
>> Hi all,
>> 
>> Postgres-XC, read&write-scalable multi-master symmetric cluster based on PostgreSQL, version 1.0.0 is released.
>> This project is seen as an open-source alternative to costly products such as OracleRAC. Postgres-XC is based on the code of PostgreSQL, so it can naturally use all its technologies, which are enhaunced to have a shared-nothing multi-master PostgreSQL-based database cluster.
>> 
>> This first stable version is based on PostgreSQL 9.1.4. All the patches in PostgreSQL 9.1 stable branch have been merged up to commit 873d1c1 (1st of June 2012).
>> This includes the security fix related to pg_crypto dated of 30th of May.
>> You can download the source tarball directly from here:
>> https://sourceforge.net/projects/postgres-xc/files/latest/download
>> This tarball contains all the HTML and man documentation.
>> 
>> 30 bug fixes have been made since release of beta2, with some notable enhancements:
>> - Support for EXTENSION is fixed
>> - Stabilization of the use of slave nodes in cluster
>> - Fix of a bug related to read-only transactions, improving performance by 15%.
>> - Support of compilation for MacOSX
>> About the scalability of this release, Postgres-XC 1.0.0 scales to a factor of 3 when compared to a standalone server PostgreSQL 9.1.3 on 5 nodes using a benchmark called DBT-1.
>> 
>> Compared to version Postgres-XC 0.9.7, the following features have been added:
>> - Fast query shipping (FQS), quick identification of expressions in a query that can be pushed down to remote nodes
>> - SERIAL types
>> - TABLESPACE
>> - Utility to clean up 2PC transactions in cluster (pgxc_clean)
>> - Utility for initialization of GTM (global transaction manager, utility called initgtm)
>> - Relation-size functions and locking functions
>> - Regression stabilization
>> 
>> The documentation of 1.0, including release notes, is available here:
>> http://postgres-xc.sourceforge.net/docs/1_0/.
>> 
>> The project can be followed on Source Forge: http://postgres-xc.sourceforge.net/.
>> And a couple of GIT repositories are used for development:
>> - SourceForge: http://postgres-xc.git.sourceforge.net/git/gitweb.cgi?p=postgres-xc/postgres-xc;a=summary
>> - Github: https://github.com/postgres-xc/postgres-xc
>> 
>> The core team is currently working in the addition of new features for the next major release including:
>> - Merge with PostgreSQL 9.2
>> - Data redistribution functionality, changing table distribution in cluster with a simple ALTER TABLE
>> - New functionalities related to online node addition and deletion for a better user experience
>> - Triggers
>> - Planner improvements
>> - Global constraints.
>> The roadmap of the project is located here => http://postgres-xc.sourceforge.net/ in section Roadmap.
>> 
>> The project is under the same license as PostgreSQL, now managed under a single entity called "Postgres-XC Development Group".
>> In order to keep in touch with the project, whose development follows the same model as PostgreSQL, you can register to the following mailing lists:
>> - pos...@li..., for general questions. Registration can be done here: https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> - pos...@li.... hachers mailing list. Registration can be done here: https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>> 
>> See you soon on the project mailing list, and have fun with this stable release.
>> -- 
>> Michael Paquier
>> Member of core team of Postgres-XC, and Postgres-XC Development Group
> 
> 

On Fri, Jun 8, 2012 at 1:20 AM, Michael Paquier
<mic...@gm...> wrote:
>
>> I have read the (just) story about bizgres and c-store, from it's
>> development progress until it was commercialized by it's developer.
>> That's so sad because the original project was not to be maintained.
>

I guess that can happen if others apart from the original developers
don't jump in.

> Postgres-XC is under BSD license (PostgreSQL license), so you can edit the
> code, copy the code and even sell it if you wish as a closed source package.
> You can also make money from it by becoming a specialist of this technology
> and sell support and consulting services.
> However there are really few specialists in the world that really understand
> deeply this kind of technology, and even lesser who can work on the code or
> design applications for clusters based on XC.
>
>> What are Postgres-XC plans, will be in the future?

A roadmap appears here:

http://postgres-xc.sourceforge.net/roadmap.html

If you are concerned if development will continue, yes, there are
plans for now.  Even outside of the originally companies involved,
others are going to contribute, too. I no longer work for one of the
original companies behind XC, but I and others intend to contribute to
the project, so I think you can be optimistic about it.

>
> Becoming a reference and a real alternative to closed source (and costly)
> solutions like one I won't give the name (Or????AC).
>
>> How to achieve them?
>
> By supporting and helping the project.
> There are several ways to support the project:
> - first learn how to use it
> - register to the mailing lists and do not hesitate to ask questions
> - report bugs, even better => report bugs and submit patches fixing them.
> - improve the documentation and submit patch for that
> - build and publish packages
> - search for funds to support developers if you want some new features
> - promote the project at conferences or by writing articles about it.
> - provide machines for buildfarming and extend the currently supported OS.
> - provide some website architecture similar to postgresql.org.
> That's all I have in mind now... However, there may be some other things
> people could do.

Good list.

Mason

On 2012/06/08, at 20:19, Michael Vitale <mic...@ar...> wrote:

> How do you undo an initdb?  In the case where I want to redefine the initdb differently.  Also, I did the gmake uninstall, but it didn't remove any binary installed files.
Let's take the problems one-by-one.
For initdb, you need to delete the data folder and then recreate it. I don't think Postgres can redefine a data folder with initdb and just returns an error telling that existing data folder is not empty.
gmaje uninstall should work. At least in the environments used here it does.
> 
> Also, does postgres-xc work well as a High Availability solution, i.e., automatic failover?
You will need to plug in yourself slave nodes to your master nodes and having  a monitoring engine that performs failover. You got the same problems with Postgres. Its core features cannot perform a failover themselves and you always need to kick something to perform a failover in case of a node failure.
> 
> I come from an oracle RAC world, and I am playing with postgres-xc 1.0.0 on 2 centos 6, 64 bit boxes.
> 
> Oracle has failover embedded in its listener configuration and in its jdbc driver.  For instance, the oracle jdbc driver for our jboss server is something like this:
> 
> <connection-url>jdbc:oracle:thin:@(description=(address_list=(load_balance=on)(failover=off)(address=(protocol=tcp)(host=odb0-vip.arin.net)(port=1521))(address=(protocol=tcp)(host=odb1-vip.arin.net)(port=1521)))(connect_data=(service_name=pjpn.arin.net)(failover_mode=(type=select)(method=basic))))</connection-url>
> 
> Note that 2 oracle nodes are specified right within the oracle jdbc driver.  For normal PostgreSQL, the driver would look something like this:
> <connection-url>jdbc:postgresql://dbproto1.arin.net:5432/pjpn</connection-url>
> 
> So, I'm wondering if there is already a way to specify more than one cordinator in the jdbc connection string for connecting to postgres-xc?
I am not a specialist of jdbc, but I don't think you can specify multiple connection points in.
> 
> If not, then I reckon its up to me to implement a vip switched node that would automatically point to another cordinator if the first vip went down.
Yep think so. The core features of xc should be sufficient for a correct failover.
> 
> Comments, suggestions?
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

How do you undo an initdb?  In the case where I want to redefine the initdb differently.  Also, I did the gmake uninstall, but it didn't remove any binary installed files.

Also, does postgres-xc work well as a High Availability solution, i.e., automatic failover?

I come from an oracle RAC world, and I am playing with postgres-xc 1.0.0 on 2 centos 6, 64 bit boxes.

Oracle has failover embedded in its listener configuration and in its jdbc driver.  For instance, the oracle jdbc driver for our jboss server is something like this:

<connection-url>jdbc:oracle:thin:@(description=(address_list=(load_balance=on)(failover=off)(address=(protocol=tcp)(host=odb0-vip.arin.net)(port=1521))(address=(protocol=tcp)(host=odb1-vip.arin.net)(port=1521)))(connect_data=(service_name=pjpn.arin.net)(failover_mode=(type=select)(method=basic))))</connection-url>

Note that 2 oracle nodes are specified right within the oracle jdbc driver.  For normal PostgreSQL, the driver would look something like this:
<connection-url>jdbc:postgresql://dbproto1.arin.net:5432/pjpn</connection-url>

So, I'm wondering if there is already a way to specify more than one cordinator in the jdbc connection string for connecting to postgres-xc?

If not, then I reckon its up to me to implement a vip switched node that would automatically point to another cordinator if the first vip went down.

Comments, suggestions?

Very nice.   The article evaluate XC technology very reasonablly.
---
Koichi

On Fri, 8 Jun 2012 12:36:42 +0900
Michael Paquier <mic...@gm...> wrote:

> Hi all,
> 
> Here is a small article about XC at PGCon:
> http://lwn.net/Articles/498853/
> 
> The project is presented as a clear initiative to OracleRAC.
> -- 
> Michael Paquier
> http://michael.otacoo.com