postgres-xc-general Mailing List for Postgres-XC (Page 3)

On Wed, Oct 24, 2012 at 07:40:33PM +0530, Nikhil Sontakke wrote:

>    "While many standard MySQL schemas and applications can work using
>    MySQL Cluster, it is also true that unmodified applications and
>    database schemas may be slightly incompatible or have suboptimal
>    performance when run using MySQL Cluster"

I was aware of this when wrote previous message.

>    So transparency might come at a cost in the case of MySQL cluster as well.

It is rare and specific cases and absolutely different thing then we have with
XC. In XC we must take care about "CREATE TABLE ... DISTRIBUTE BY ..."
EVERYWHERE and ALWAYS.


>    In general Postgres has all along believed that the user is more
>    intelligent and will take the pains to understand the nuances of
>    their use case and configure the database accordingly. That's why

Again it is different things. It is not configuration of database. It
is rewriting installation sql scripts. Imagine if You need install third
party application. What about upgrade? And what about lot of such
applications? No, it is not acceptable for production.

This is example of core of my claims here: You don't think about real life
and production environment.


>    perhaps even the stock postgresql.conf configuration file is pretty
>    conservative and users tweak it as per their requirements.

To edit configuration file postgresql.conf is good idea, but rewriting
installation sql script every time is very bad idea.

>      Impossibility to extend cluster online means it is not scalable.
> 
>    As you rightly mention below, this is indeed a "young" project and IMHO it's maturing along proper lines.

Good news. News is that You agree with me in something.

>      Again: it should not be external tool, it should be internal,
>      integral, essential feature.
> 
>    Some people will say exactly the opposite. Why add something

Didn't hear.

>    minimal internal support. Like for example the Corosync/Pacemaker
>    LinuxHA product maybe along with some of the tools that Suzuki san

That is exactly what I am using. But it is not an alternative for internal
solution.

>    applications, the XC cluster continues to function.  As long as
>    datanodes are equipped with replication and an HA strategy is in
>    place to handle datanodes going down and failing over to a promoted
>    standby,  then again the cluster continues to function.

Good. But bad thing is that with any external solution You should twice
Your hardware park for data nodes, because only half of them will be
under work load. This is essential and main reason why solution should
be internal. The next one is manageability and complexity of whole
system.

>    Here seems to be the fundamental difference between mysql cluster
>    and PGXC. Everything appears to be "replicated" in MySQL cluster
>    and all nodes are mirror images of each other. In PGXC, data can be
>    partitioned across nodes as well. It is for this that we provide
>    the flexibility to the user via the DISTRIBUTE BY clause.

It seems only, but is not true. All data are distributed between groups
of data nodes. Replicas are inside group only.

>    AIUI, all Mysql nodes are images of each other. While that's good
>    for reads, that is not so good for writes, no?

No, see above.

>    Data node addition is a work in progress in XC currently.

I saw already:

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

But it is issue of priority.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

Hi Vladimir,

Thanks for your very frank perspectives on PGXC.


> >    Sure, XC provides thanks to its architecture naturally transparency
> and scalability.
>
> What does XC provides? My two rhetorical questions above imply answers
> "NO".  Necessity to adapt application means cluster is not transparent.
>

Well even the MySQL cluster documentation states the below:

"While many standard MySQL schemas and applications can work using MySQL
Cluster, it is also true that unmodified applications and database schemas
may be slightly incompatible or have suboptimal performance when run using
MySQL Cluster"

So transparency might come at a cost in the case of MySQL cluster as well.

In general Postgres has all along believed that the user is more
intelligent and will take the pains to understand the nuances of their use
case and configure the database accordingly. That's why perhaps even the
stock postgresql.conf configuration file is pretty conservative and users
tweak it as per their requirements.


> Impossibility to extend cluster online means it is not scalable.
>
>
As you rightly mention below, this is indeed a "young" project and IMHO
it's maturing along proper lines.


> More over, this two issues are interrelated, because You should rewrite
> "CREATE TABLE" statement every time you expand (read: recreate) Your
> cluster. But this issue looks much worse if node fails containing tables
> with different distributed schemas. This is uncontrollable model.
>
> >    Load balancing can be provided between Coordinator and Datanodes
> >    depending on applications, or at Coordinator level
>
> It should not depend on application, it should be an cluster's global
> function.
>
> >    For HA, Koichi is currently working on some tools to provide that,
>
> Again: it should not be external tool, it should be internal, integral,
> essential feature.
>
>
Some people will say exactly the opposite. Why add something internal when
off-the-shelf technologies can help with minimal internal support. Like for
example the Corosync/Pacemaker LinuxHA product maybe along with some of the
tools that Suzuki san has provided can be combined with the replication
capabilities that Postgres (and PGXC) provides.

Infact with synchronous replication in place, a properly architected
solution using the above packages can provide very good HA capabilities.
There's already redundancy for the coordinator nodes.

>    I am not sure you can that easily compare XC and mysql cluster,
> >    both share the same architectures, but once of the main
>
> I don't know what there is "the same", but in functionality it is
> totally different. Mysql cluster has the precise and clear clustering
> model:
>
> 1. If some nodes fail cluster continues to work as soon as there remains
> at least one healthy node in every group.
>
>
As long as one coordinator node is around and reachable to applications,
the XC cluster continues to function.

As long as datanodes are equipped with replication and an HA strategy is in
place to handle datanodes going down and failing over to a promoted
standby,  then again the cluster continues to function.


> 2. No "CREATE TABLE ... DISTRIBUTE BY ..." statement. You just define
> the number of replicas at configuration level. Yes, now there are only
> one option is available that make sense with two replicas, but it is
> enough.
>
>
Here seems to be the fundamental difference between mysql cluster and PGXC.
Everything appears to be "replicated" in MySQL cluster and all nodes are
mirror images of each other. In PGXC, data can be partitioned across nodes
as well. It is for this that we provide the flexibility to the user via the
DISTRIBUTE BY clause.


> 3. Read and write scalability (i.e. LB) at the same time for all tables
> (i.e. on the cluster level).
>
>
AIUI, all Mysql nodes are images of each other. While that's good for
reads, that is not so good for writes, no?


> 4. You can add data node online, i.e. without restarting (not to mention
> "recreating" as for XC) cluster. Yes, only new data will go to the new
> node in this case. But You can totally redistribute it with restart.
>
> So it is full flagged cluster, that's not true for XC and it's a pity.
>
>
Data node addition is a work in progress in XC currently.


>  >    differences coming to my mind is that XC is far more flexible in
> >    terms of license (BSD and not GPL), and like PostgreSQL, no company
> >    has the control of its code like mysql products which Oracle relies
>
> Yes, and this is why I am persuading all developers migrate to
> Postgresql. But it is off topic here where we are discussing
> functionality, but not an licence issues.
>
> Be tolerant to my criticism, I wouldn't say You made bad thing, I was
> amazing when first read "write-scalable, synchronous multi-master,
> transparent PostgreSQL cluster" in Your description that I completely
> and exactly copied into description of my debian package, but I was
> notably disappointed after my first test showing me that it is odd with
> reality. It would not be so bad itself, as soon as it is young project,
> but much worse that this discussion shows there are something wrong with
> Your priorities and fundamental approach.
>
>
Criticism is welcome. It helps us improve the product as we go along :)

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Wed, Oct 24, 2012 at 08:08:32PM +0900, Michael Paquier wrote:

>    Sure, XC provides thanks to its architecture naturally transparency and scalability.

What does XC provides? My two rhetorical questions above imply answers
"NO".  Necessity to adapt application means cluster is not transparent.
Impossibility to extend cluster online means it is not scalable.

More over, this two issues are interrelated, because You should rewrite
"CREATE TABLE" statement every time you expand (read: recreate) Your
cluster. But this issue looks much worse if node fails containing tables
with different distributed schemas. This is uncontrollable model.

>    Load balancing can be provided between Coordinator and Datanodes
>    depending on applications, or at Coordinator level

It should not depend on application, it should be an cluster's global function.

>    For HA, Koichi is currently working on some tools to provide that,

Again: it should not be external tool, it should be internal, integral,
essential feature.

>    I am not sure you can that easily compare XC and mysql cluster,
>    both share the same architectures, but once of the main

I don't know what there is "the same", but in functionality it is
totally different. Mysql cluster has the precise and clear clustering
model:

1. If some nodes fail cluster continues to work as soon as there remains
at least one healthy node in every group.

2. No "CREATE TABLE ... DISTRIBUTE BY ..." statement. You just define
the number of replicas at configuration level. Yes, now there are only
one option is available that make sense with two replicas, but it is
enough.

3. Read and write scalability (i.e. LB) at the same time for all tables
(i.e. on the cluster level).

4. You can add data node online, i.e. without restarting (not to mention
"recreating" as for XC) cluster. Yes, only new data will go to the new
node in this case. But You can totally redistribute it with restart.

So it is full flagged cluster, that's not true for XC and it's a pity.

>    differences coming to my mind is that XC is far more flexible in
>    terms of license (BSD and not GPL), and like PostgreSQL, no company
>    has the control of its code like mysql products which Oracle relies

Yes, and this is why I am persuading all developers migrate to
Postgresql. But it is off topic here where we are discussing
functionality, but not an licence issues. 

Be tolerant to my criticism, I wouldn't say You made bad thing, I was
amazing when first read "write-scalable, synchronous multi-master,
transparent PostgreSQL cluster" in Your description that I completely
and exactly copied into description of my debian package, but I was
notably disappointed after my first test showing me that it is odd with
reality. It would not be so bad itself, as soon as it is young project,
but much worse that this discussion shows there are something wrong with
Your priorities and fundamental approach.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On Wed, Oct 24, 2012 at 5:38 PM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Wed, Aug 01, 2012 at 06:22:27PM +0900, Michael Paquier wrote:
>
> >>      I thought HA & LB is main feature of any cluster.
> >
> >    Transparency and scalability are even more important.
>
> Really? If You should rewrite every "CREATE TABLE" statement, when You
> need write scalability, is it "Transparency"? And if You should recreate
> entire cluster from scratch, when You need to add a node, is it
> "scalability"?
>
> It is hard to imagine who will use in production environment such
> cluster without HA, LB, transparency and scalability. I don't want to
> compare Your creature with mysql cluster at least because it is in
> memory database, but it has all of those features, absolutely
> necessary for any cluster.
>
Sure, XC provides thanks to its architecture naturally transparency and
scalability.
Load balancing can be provided between Coordinator and Datanodes depending
on applications, or at Coordinator level using an extra layer providing
this functionality.
For HA, Koichi is currently working on some tools to provide that, tools
you can find here:
https://github.com/koichi-szk/PGXC-Tools

Like Postgres, you need an external application to provide it.

I am not sure you can that easily compare XC and mysql cluster, both share
the same architectures, but once of the main differences coming to my mind
is that XC is far more flexible in terms of license (BSD and not GPL), and
like PostgreSQL, no company has the control of its code like mysql products
which Oracle relies on.
-- 
Michael Paquier
http://michael.otacoo.com

On Wed, Oct 24, 2012 at 2:14 PM, Paulo Pires <pj...@ub...> wrote:

>
> On 03/10/12 00:25, Michael Paquier wrote:
>
>
>
> On Wed, Oct 3, 2012 at 2:27 AM, Paulo Pires <pj...@ub...> wrote:
>
>>
>>
>> On Tue Sep 18 11:21:21 2012, Michael Paquier wrote:
>> >
>> >
>> > On Tue, Sep 18, 2012 at 5:43 PM, Paulo Pires <pj...@ub...
>>  > <mailto:pj...@ub...>> wrote:
>> >
>> >     Hi Michael,
>> >
>> >     Thanks so much for your support.
>> >
>> >     Could you tell me if I should follow postgres-xc-developers@ or
>> >     postgres-xc-committers in order to be notified as soon as
>> >     RETURNING support is implemented?
>> >
>> > Sure.
>> > - The mailing list developper is used for conversations about features
>> > and patches, so you will be notified about the commit in GIT with that.
>> > - The commit mailing list is a mailing list where an email is sent
>> > automatically where there is a commit in GIT. So you should follow it.
>> >
>> > You can also follow this twitter bot: https://twitter.com/PostgresXCBot
>> .
>> > This bot sends a tweet automatically when a commit is made with the
>> > header of the commit.
>> > You can also see the list of commits on Github:
>> > https://github.com/postgres-xc/postgres-xc/commits/master
>>
>>  Last updates are from Sep 16th, so I think you don't make any "beta"
>> available. Am I wrong?
>>
> Well, I am working on the implementation of triggers, which is not that
> straightforward.
> So it requires time. The next beta of XC is planned for March or April.
>
>
>>
>> >
>> > I also don't mind dropping an email on the thread where you discussed
>> > about RETURNING on general mailing list once the stuff is committed.
>>
>>  That would be awesome. I'm really needing this to continue my tests.
>>
> Regarding RETURNING, Abbas is working on that.
> He just needs more time to stabilize his patch as he is cleaning a lot of
> things, including things planner for remote query generation.
>
> Is this landing on master? I have been unable to find other development
> branches and even Abbas. I can only see you and Ashutosh as committers.
>

Yes it will land on the master, there are no other dev branches.


>
>
>    --
> Michael Paquier
> http://michael.otacoo.com
>
>
> --
> Paulo Pires
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> 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.

On Wed, Oct 24, 2012 at 6:14 PM, Paulo Pires <pj...@ub...> wrote:

>
> On 03/10/12 00:25, Michael Paquier wrote:
>
>
>
> On Wed, Oct 3, 2012 at 2:27 AM, Paulo Pires <pj...@ub...> wrote:
>
>>
>>
>> On Tue Sep 18 11:21:21 2012, Michael Paquier wrote:
>> >
>> >
>> > On Tue, Sep 18, 2012 at 5:43 PM, Paulo Pires <pj...@ub...
>>  > <mailto:pj...@ub...>> wrote:
>> >
>> >     Hi Michael,
>> >
>> >     Thanks so much for your support.
>> >
>> >     Could you tell me if I should follow postgres-xc-developers@ or
>> >     postgres-xc-committers in order to be notified as soon as
>> >     RETURNING support is implemented?
>> >
>> > Sure.
>> > - The mailing list developper is used for conversations about features
>> > and patches, so you will be notified about the commit in GIT with that.
>> > - The commit mailing list is a mailing list where an email is sent
>> > automatically where there is a commit in GIT. So you should follow it.
>> >
>> > You can also follow this twitter bot: https://twitter.com/PostgresXCBot
>> .
>> > This bot sends a tweet automatically when a commit is made with the
>> > header of the commit.
>> > You can also see the list of commits on Github:
>> > https://github.com/postgres-xc/postgres-xc/commits/master
>>
>>  Last updates are from Sep 16th, so I think you don't make any "beta"
>> available. Am I wrong?
>>
> Well, I am working on the implementation of triggers, which is not that
> straightforward.
> So it requires time. The next beta of XC is planned for March or April.
>
>
>>
>> >
>> > I also don't mind dropping an email on the thread where you discussed
>> > about RETURNING on general mailing list once the stuff is committed.
>>
>>  That would be awesome. I'm really needing this to continue my tests.
>>
> Regarding RETURNING, Abbas is working on that.
> He just needs more time to stabilize his patch as he is cleaning a lot of
> things, including things planner for remote query generation.
>
> Is this landing on master? I have been unable to find other development
> branches and even Abbas. I can only see you and Ashutosh as committers.
>
Yes this is planned for master. He is working on it and there will be more
stuff soon.
Abbas is also a committer, just that he is not really committing a lot of
things these days.
-- 
Michael Paquier
http://michael.otacoo.com

On 03/10/12 00:25, Michael Paquier wrote:
>
>
> On Wed, Oct 3, 2012 at 2:27 AM, Paulo Pires <pj...@ub...
> <mailto:pj...@ub...>> wrote:
>
>
>
>     On Tue Sep 18 11:21:21 2012, Michael Paquier wrote:
>     >
>     >
>     > On Tue, Sep 18, 2012 at 5:43 PM, Paulo Pires
>     <pj...@ub... <mailto:pj...@ub...>
>     > <mailto:pj...@ub... <mailto:pj...@ub...>>> wrote:
>     >
>     >     Hi Michael,
>     >
>     >     Thanks so much for your support.
>     >
>     >     Could you tell me if I should follow postgres-xc-developers@ or
>     >     postgres-xc-committers in order to be notified as soon as
>     >     RETURNING support is implemented?
>     >
>     > Sure.
>     > - The mailing list developper is used for conversations about
>     features
>     > and patches, so you will be notified about the commit in GIT
>     with that.
>     > - The commit mailing list is a mailing list where an email is sent
>     > automatically where there is a commit in GIT. So you should
>     follow it.
>     >
>     > You can also follow this twitter bot:
>     https://twitter.com/PostgresXCBot.
>     > This bot sends a tweet automatically when a commit is made with the
>     > header of the commit.
>     > You can also see the list of commits on Github:
>     > https://github.com/postgres-xc/postgres-xc/commits/master
>
>     Last updates are from Sep 16th, so I think you don't make any "beta"
>     available. Am I wrong?
>
> Well, I am working on the implementation of triggers, which is not
> that straightforward.
> So it requires time. The next beta of XC is planned for March or April.
>  
>
>
>     >
>     > I also don't mind dropping an email on the thread where you
>     discussed
>     > about RETURNING on general mailing list once the stuff is committed.
>
>     That would be awesome. I'm really needing this to continue my tests.
>
> Regarding RETURNING, Abbas is working on that.
> He just needs more time to stabilize his patch as he is cleaning a lot
> of things, including things planner for remote query generation.
Is this landing on master? I have been unable to find other development
branches and even Abbas. I can only see you and Ashutosh as committers.

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

-- 
Paulo Pires

On Wed, Aug 01, 2012 at 06:22:27PM +0900, Michael Paquier wrote:

>>      I thought HA & LB is main feature of any cluster.
> 
>    Transparency and scalability are even more important.

Really? If You should rewrite every "CREATE TABLE" statement, when You
need write scalability, is it "Transparency"? And if You should recreate
entire cluster from scratch, when You need to add a node, is it
"scalability"?

It is hard to imagine who will use in production environment such
cluster without HA, LB, transparency and scalability. I don't want to
compare Your creature with mysql cluster at least because it is in
memory database, but it has all of those features, absolutely
necessary for any cluster.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On Wed, Oct 17, 2012 at 3:01 PM, Roger Mayes <rog...@gm...>wrote:

> Ok, I put this together in a test action, completely separate from
> anything to do with the rest of my code base, just to be sure it's pdo..
>
>         // $conn = Zend_Db::factory('Pdo_Pgsql', $connArgs);
>         $conn = new PDO('pgsql:host=localhost;dbname=devdb', 'postgres',
> '');
>         $statement = $conn->query("select now()");
>         echo "<pre>";
>         echo print_r($statement->fetchAll(), true);
>         echo "</pre>";
>         $conn = null;
>
> That script doesn't  ...
>
> Eh, hmm.  Nope, that script works fine.  Poo.  So the problem is with my
> code, somehow.  Awesome.  Meh, yeah, it works with Zend_Db, etc., too.
>  Well, on the bright side, now zend / php / pdo has been specifically
> tested.
>
Nice to know it works normally. Thanks.
-- 
Michael Paquier
http://michael.otacoo.com

Ok, I put this together in a test action, completely separate from anything
to do with the rest of my code base, just to be sure it's pdo..

        // $conn = Zend_Db::factory('Pdo_Pgsql', $connArgs);
        $conn = new PDO('pgsql:host=localhost;dbname=devdb', 'postgres',
'');
        $statement = $conn->query("select now()");
        echo "<pre>";
        echo print_r($statement->fetchAll(), true);
        echo "</pre>";
        $conn = null;

That script doesn't  ...

Eh, hmm.  Nope, that script works fine.  Poo.  So the problem is with my
code, somehow.  Awesome.  Meh, yeah, it works with Zend_Db, etc., too.
 Well, on the bright side, now zend / php / pdo has been specifically
tested.



On Tue, Oct 16, 2012 at 8:35 PM, Michael Paquier
<mic...@gm...>wrote:

>
>
> On Wed, Oct 17, 2012 at 12:09 PM, Shavais Zarathustra <sh...@gm...>wrote:
>
>>
>> I've been trying to get the php pdo driver for postgres (php extension
>> pdo_pgsql.so) to work with postgres-xc today, so far with no luck.  It
>> seems to give me a valid connection, but when I try to use
>> $conn->query($sql) or $stmt = $conn->prepare(..)  .. $stmt->execute(), no
>> exceptions are thrown, even for obviously incorrect sql, and no results are
>> fetchable even for trivial sql.  From the terminal, psql is working fine, I
>> can connect and run sql statements and so on, so it seems like the cluster
>> is operating and so forth.
>>
> I haven't used php with XC for a certain amount of time, but as XC uses
> the same connection interface as Postgres, so I do not see why it shouldn't
> work. For example I did some tests with jdbc and perl drivers this week and
> it was working correctly.
> Could you give an example of the SQLs that are not working? Or even a
> script?
> --
> Michael Paquier
> http://michael.otacoo.com
>

On Wed, Oct 17, 2012 at 12:09 PM, Shavais Zarathustra <sh...@gm...>wrote:

>
> I've been trying to get the php pdo driver for postgres (php extension
> pdo_pgsql.so) to work with postgres-xc today, so far with no luck.  It
> seems to give me a valid connection, but when I try to use
> $conn->query($sql) or $stmt = $conn->prepare(..)  .. $stmt->execute(), no
> exceptions are thrown, even for obviously incorrect sql, and no results are
> fetchable even for trivial sql.  From the terminal, psql is working fine, I
> can connect and run sql statements and so on, so it seems like the cluster
> is operating and so forth.
>
I haven't used php with XC for a certain amount of time, but as XC uses the
same connection interface as Postgres, so I do not see why it shouldn't
work. For example I did some tests with jdbc and perl drivers this week and
it was working correctly.
Could you give an example of the SQLs that are not working? Or even a
script?
-- 
Michael Paquier
http://michael.otacoo.com

I've been trying to get the php pdo driver for postgres (php extension
pdo_pgsql.so) to work with postgres-xc today, so far with no luck.  It
seems to give me a valid connection, but when I try to use
$conn->query($sql) or $stmt = $conn->prepare(..)  .. $stmt->execute(), no
exceptions are thrown, even for obviously incorrect sql, and no results are
fetchable even for trivial sql.  From the terminal, psql is working fine, I
can connect and run sql statements and so on, so it seems like the cluster
is operating and so forth.

Is pdo_pgsql.so working for you guys?

Hi, Michael

Thank you for answer.

 >> I've understood that it's safe to execute against datanode on higher
 >> version of Postgres-XC 1.0.1.
 >> Is this right?
 >>
 > Yes. The read queries are made MVCC-safe when launched directly to
 > Datanodes, so you can have a direct access to the statistics of datanodes
 > by directly connecting to them or monitor them with things like 
Nagios. But
 > you have to be aware that write queries are not blocked in 1.0.X releases
 > when launched directly to Datanodes and this is extremely dangerous 
as you
 > might break data consistency in cluster. Use only read queries!
 >
Alright.
I'll be careful of breaking data consistency.

 > The code on master is made safer and blocks write queries when an
 > application connects to a Datanode that tries to launch a query that may
 > change Database, like a Postgres HOT standby would do.
 >
It's good news.
I'll check the master code.

Thank you again.

regards,
--------
Tomonari Katsumata

On Thu, Oct 11, 2012 at 9:12 PM, Tomonari Katsumata <
kat...@po...> wrote:

> Hi,
>
> When I use Postgres-XC 1.0.0 and execute a query against datanode,
> I get below WARNING messages.
> ------------------------------------
> Do not have a GTM snapshot available
> ------------------------------------
>
> When I use Postgres-XC 1.0.1 and execute a query against datanode,
> I don't any WARNING messages.
>
> I think it's because of below changes.
> ---
> ref.)Release Note
> - Fix snapshot management on slave nodes and on Datanodes accessed
> directly by applications (Michael Paquier)
>

> A slave node session acquires its snapshot directly from WAL like
> PostgreSQL does. Also, a Datanode is now able to get a global snapshot
> directly from GTM, avoiding WARNING messages that a snapshot is not
> available.
>
> Queries interacting with remote nodes running on slave nodes are blocked.
> Such queries need a global snapshot and a new transaction ID, but
> sessions on
> slave nodes cannot acquire that.
> ---
>
> I've understood that it's safe to execute against datanode on higher
> version of Postgres-XC 1.0.1.
> Is this right?
>
Yes. The read queries are made MVCC-safe when launched directly to
Datanodes, so you can have a direct access to the statistics of datanodes
by directly connecting to them or monitor them with things like Nagios. But
you have to be aware that write queries are not blocked in 1.0.X releases
when launched directly to Datanodes and this is extremely dangerous as you
might break data consistency in cluster. Use only read queries!

The code on master is made safer and blocks write queries when an
application connects to a Datanode that tries to launch a query that may
change Database, like a Postgres HOT standby would do.
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

When I use Postgres-XC 1.0.0 and execute a query against datanode,
I get below WARNING messages.
------------------------------------
Do not have a GTM snapshot available
------------------------------------

When I use Postgres-XC 1.0.1 and execute a query against datanode,
I don't any WARNING messages.

I think it's because of below changes.
---
ref.)Release Note
- Fix snapshot management on slave nodes and on Datanodes accessed
directly by applications (Michael Paquier)

A slave node session acquires its snapshot directly from WAL like
PostgreSQL does. Also, a Datanode is now able to get a global snapshot
directly from GTM, avoiding WARNING messages that a snapshot is not
available.

Queries interacting with remote nodes running on slave nodes are blocked.
Such queries need a global snapshot and a new transaction ID, but
sessions on
slave nodes cannot acquire that.
---

I've understood that it's safe to execute against datanode on higher
version of Postgres-XC 1.0.1.
Is this right?

---------
Tomonari Katsumata

On Wed, Oct 3, 2012 at 2:27 AM, Paulo Pires <pj...@ub...> wrote:

>
>
> On Tue Sep 18 11:21:21 2012, Michael Paquier wrote:
> >
> >
> > On Tue, Sep 18, 2012 at 5:43 PM, Paulo Pires <pj...@ub...
> > <mailto:pj...@ub...>> wrote:
> >
> >     Hi Michael,
> >
> >     Thanks so much for your support.
> >
> >     Could you tell me if I should follow postgres-xc-developers@ or
> >     postgres-xc-committers in order to be notified as soon as
> >     RETURNING support is implemented?
> >
> > Sure.
> > - The mailing list developper is used for conversations about features
> > and patches, so you will be notified about the commit in GIT with that.
> > - The commit mailing list is a mailing list where an email is sent
> > automatically where there is a commit in GIT. So you should follow it.
> >
> > You can also follow this twitter bot: https://twitter.com/PostgresXCBot.
> > This bot sends a tweet automatically when a commit is made with the
> > header of the commit.
> > You can also see the list of commits on Github:
> > https://github.com/postgres-xc/postgres-xc/commits/master
>
> Last updates are from Sep 16th, so I think you don't make any "beta"
> available. Am I wrong?
>
Well, I am working on the implementation of triggers, which is not that
straightforward.
So it requires time. The next beta of XC is planned for March or April.


>
> >
> > I also don't mind dropping an email on the thread where you discussed
> > about RETURNING on general mailing list once the stuff is committed.
>
> That would be awesome. I'm really needing this to continue my tests.
>
Regarding RETURNING, Abbas is working on that.
He just needs more time to stabilize his patch as he is cleaning a lot of
things, including things planner for remote query generation.
-- 
Michael Paquier
http://michael.otacoo.com