postgres-xc-general Mailing List for Postgres-XC

Hi,

On Mon, Jan 23, 2012 at 11:26 PM, Magorn <ma...@gm...> wrote:

> I'm looking for release notes about 0.9.7. Where i find it ?
>
There are no release notes in the postgres-fashion, but you can find a list
of new functionalities here:
http://postgres-xc.sourceforge.net/roadmap.html
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi,
I'm looking for release notes about 0.9.7. Where i find it ?
Regards,

-- 
Magorn

Hi Koichi,
I didn't search feature about big data in postgress-xc. I search something
like ORACLE RAC.
Cluste Avaibility, load balancing, auto rebalancing connection to alive
node when node is stops/break.
Big data is for BI system (very big BI system), i work with OLTP
application, my except is around OLTP.

My interset about NoSQL system, it's how it run and is it possible copy
some feature to SQL system ?
I see also about In memory Datagrid like EHCache, Infinispan or Coherence,
data always available in memory distributed on several servers.

Regards,


On Tue, Jan 10, 2012 at 3:00 AM, Koichi Suzuki <ko...@in...>wrote:

> You're running so many DBMSs.   What do you expect in XC?  As I wrote, XC
> runs as a background for Hive and Sqoop.   Do you think XC can contribute
> to this type of application?  We're now focusing in OLTP like application
> so far, although XC can be applicable for analytic applicaiton too.   My
> idea is to use SQL/MED type mechanism for big data analysis, but asking to
> have "agent" for each piece of data to help scan/join/aggregate.   This
> will eliminate the current needs to load "everything" to the database for
> analysis.   "Agent" and "SQL/MED" can integrate any data source to SQL
> statements without re-loading.
>
> Object-oriented SQL extension will be useful too, for example,
> path-expression to traverse object chain, which is described in
> "Introduction to Object-Oriented Datbases" by Won Kim.   This is one on my
> favorite because this will simplify many indirect sub-queries and will be
> more intuitive.    Anyway, I'd like to learn much more about what we need
> for big data analysis.
>
> Regards;
> ---
> Koichi Suzuki
>


-- 
Magorn

You're running so many DBMSs.   What do you expect in XC?  As I wrote, XC runs as a background for Hive and Sqoop.   Do you think XC can contribute to this type of application?  We're now focusing in OLTP like application so far, although XC can be applicable for analytic applicaiton too.   My idea is to use SQL/MED type mechanism for big data analysis, but asking to have "agent" for each piece of data to help scan/join/aggregate.   This will eliminate the current needs to load "everything" to the database for analysis.   "Agent" and "SQL/MED" can integrate any data source to SQL statements without re-loading.

Object-oriented SQL extension will be useful too, for example, path-expression to traverse object chain, which is described in "Introduction to Object-Oriented Datbases" by Won Kim.   This is one on my favorite because this will simplify many indirect sub-queries and will be more intuitive.    Anyway, I'd like to learn much more about what we need for big data analysis.

Regards;
---
Koichi Suzuki

On Fri, 6 Jan 2012 13:38:05 +0100
Magorn <ma...@gm...> wrote:

> Hi Koichi,
> I have a dba job on Oracle, PostgreSQL and ... later this year SQLServer.
> I have some interest about distributed computing and databases like
> Cassandra, MogoDB, HBase, ...
> Regards,
> 
> On Fri, Jan 6, 2012 at 1:24 AM, Koichi Suzuki <ko...@in...>wrote:
> 
> > Even juust ideas/proposals are very helpful.   I'd like to learn more
> > about your background.
> >
> > Regards;
> > ---
> > Koichi
> >
> > On Thu, 5 Jan 2012 22:14:37 +0100
> > Magorn <ma...@gm...> wrote:
> >
> > > On Thu, Jan 5, 2012 at 1:35 AM, Koichi Suzuki <koi...@gm...>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Running nodes while some of others don't work makes sense only for
> > > > read only transaction.   Update transaction in such situation will end
> > > > up with inconsistent database state.   This is basically why XC does
> > > > not allow such situation.
> > > >
> > > > Please understand that node removal, which will be an issue beyond
> > > > V1.0, should be done in consistent state, that is, all the node should
> > > > be healthy at the removal operation.   If any of them fails, we need
> > > > backup to fail over such nodes by streaming replication or other
> > > > means.
> > > >
> > > > This is what we are assuming.
> > > >
> > > > I welcome any other ideas and proposals of features.   If it comes
> > > > with a patch, this will accelerate the development.
> > > >
> > > > Regards;
> > > > ----------
> > > > Koichi Suzuki
> > > >
> > > >
> > > Hi,
> > > Thank's all for your answers.
> > > I understand your point of view and the postgres-xc situation.
> > > Sorry, but i can help you to write some patch ;) my C is not "fluent" but
> > > i'll continue to follow the evolution of postgress-xc.
> > > Regards,
> > >
> > > --
> > > Magorn
> >
> 
> 
> 
> -- 
> Magorn

Hi Koichi,
I have a dba job on Oracle, PostgreSQL and ... later this year SQLServer.
I have some interest about distributed computing and databases like
Cassandra, MogoDB, HBase, ...
Regards,

On Fri, Jan 6, 2012 at 1:24 AM, Koichi Suzuki <ko...@in...>wrote:

> Even juust ideas/proposals are very helpful.   I'd like to learn more
> about your background.
>
> Regards;
> ---
> Koichi
>
> On Thu, 5 Jan 2012 22:14:37 +0100
> Magorn <ma...@gm...> wrote:
>
> > On Thu, Jan 5, 2012 at 1:35 AM, Koichi Suzuki <koi...@gm...>
> wrote:
> >
> > > Hi,
> > >
> > > Running nodes while some of others don't work makes sense only for
> > > read only transaction.   Update transaction in such situation will end
> > > up with inconsistent database state.   This is basically why XC does
> > > not allow such situation.
> > >
> > > Please understand that node removal, which will be an issue beyond
> > > V1.0, should be done in consistent state, that is, all the node should
> > > be healthy at the removal operation.   If any of them fails, we need
> > > backup to fail over such nodes by streaming replication or other
> > > means.
> > >
> > > This is what we are assuming.
> > >
> > > I welcome any other ideas and proposals of features.   If it comes
> > > with a patch, this will accelerate the development.
> > >
> > > Regards;
> > > ----------
> > > Koichi Suzuki
> > >
> > >
> > Hi,
> > Thank's all for your answers.
> > I understand your point of view and the postgres-xc situation.
> > Sorry, but i can help you to write some patch ;) my C is not "fluent" but
> > i'll continue to follow the evolution of postgress-xc.
> > Regards,
> >
> > --
> > Magorn
>



-- 
Magorn

Even juust ideas/proposals are very helpful.   I'd like to learn more about your background.

Regards;
---
Koichi

On Thu, 5 Jan 2012 22:14:37 +0100
Magorn <ma...@gm...> wrote:

> On Thu, Jan 5, 2012 at 1:35 AM, Koichi Suzuki <koi...@gm...> wrote:
> 
> > Hi,
> >
> > Running nodes while some of others don't work makes sense only for
> > read only transaction.   Update transaction in such situation will end
> > up with inconsistent database state.   This is basically why XC does
> > not allow such situation.
> >
> > Please understand that node removal, which will be an issue beyond
> > V1.0, should be done in consistent state, that is, all the node should
> > be healthy at the removal operation.   If any of them fails, we need
> > backup to fail over such nodes by streaming replication or other
> > means.
> >
> > This is what we are assuming.
> >
> > I welcome any other ideas and proposals of features.   If it comes
> > with a patch, this will accelerate the development.
> >
> > Regards;
> > ----------
> > Koichi Suzuki
> >
> >
> Hi,
> Thank's all for your answers.
> I understand your point of view and the postgres-xc situation.
> Sorry, but i can help you to write some patch ;) my C is not "fluent" but
> i'll continue to follow the evolution of postgress-xc.
> Regards,
> 
> -- 
> Magorn

On Thu, Jan 5, 2012 at 1:35 AM, Koichi Suzuki <koi...@gm...> wrote:

> Hi,
>
> Running nodes while some of others don't work makes sense only for
> read only transaction.   Update transaction in such situation will end
> up with inconsistent database state.   This is basically why XC does
> not allow such situation.
>
> Please understand that node removal, which will be an issue beyond
> V1.0, should be done in consistent state, that is, all the node should
> be healthy at the removal operation.   If any of them fails, we need
> backup to fail over such nodes by streaming replication or other
> means.
>
> This is what we are assuming.
>
> I welcome any other ideas and proposals of features.   If it comes
> with a patch, this will accelerate the development.
>
> Regards;
> ----------
> Koichi Suzuki
>
>
Hi,
Thank's all for your answers.
I understand your point of view and the postgres-xc situation.
Sorry, but i can help you to write some patch ;) my C is not "fluent" but
i'll continue to follow the evolution of postgress-xc.
Regards,

-- 
Magorn

Hi,

Running nodes while some of others don't work makes sense only for
read only transaction.   Update transaction in such situation will end
up with inconsistent database state.   This is basically why XC does
not allow such situation.

Please understand that node removal, which will be an issue beyond
V1.0, should be done in consistent state, that is, all the node should
be healthy at the removal operation.   If any of them fails, we need
backup to fail over such nodes by streaming replication or other
means.

This is what we are assuming.

I welcome any other ideas and proposals of features.   If it comes
with a patch, this will accelerate the development.

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



2012/1/4 Ashutosh Bapat <ash...@en...>:
> Hi Magorn,
> Your expectation is right, but as of now, Postgres-XC is not so intelligent
> to understand that it can get the data from the node, which is up and thus
> choose the node which is running over the one which is shut down. In your
> case, it mostly chooses the node which is shut down thus giving the error.
>
> I think it will be a good feature to have.
>
> Regarding your question related to shutting down a server without disturbing
> rest of the cluster - As of now, Postgres-XC is not dynamic, in the sense,
> we can not add or remove nodes at will, neither can we boot or shut them
> down at will. That's something on the list of desirable feature.
>
> On Wed, Jan 4, 2012 at 7:17 PM, Magorn <ma...@gm...> wrote:
>>
>> Hi,
>>
>> I have question about Postgres-XC. I have test it with 2 node, i create
>> "distribute by replication" table. I do some insert.
>> I do SELECT and i see all my records. That's fine :)
>>
>> Next i shutdown one datanode, and i do SELECT that it fail with error :
>> ERROR:  Failed to get pooled connections .
>>
>> Is it normal ? And if is it, when cluster have a lot of node, how stop
>> some node for changer server for example without bloc all the cluser ?
>>
>> Perhaps i miss something about feature of postgres-xc.
>>
>> Regards,
>>
>> --
>> Magorn
>>
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>

On Wed, Jan 4, 2012 at 10:47 PM, Magorn <ma...@gm...> wrote:

> Hi,
>
> I have question about Postgres-XC. I have test it with 2 node, i create
> "distribute by replication" table. I do some insert.
> I do SELECT and i see all my records. That's fine :)
>
> Next i shutdown one datanode, and i do SELECT that it fail with error :
> ERROR:  Failed to get pooled connections .
>
> Is it normal ? And if is it, when cluster have a lot of node, how stop
> some node for changer server for example without bloc all the cluser ?
>
> Perhaps i miss something about feature of postgres-xc.
>
As said before by Ashutosh, you are missing nothing. For the time being XC
is made to run with a constant number of Coordinators and Datanodes.
There are already basics to have support for dynamic addition and deletion
of nodes, and we are working on strengthening the cluster setup to maintain
global consistency. However, such features as the one you mentionned is
something different that we may target after 1.0 is out.

In case you are also interested in the feature regarding node selection of
a replicated table that fails, you could also give a try and propose a
feature spec to write a patch.
-- 
Thanks,

Michael Paquier
http://michael.otacoo.com

Hi Magorn,
Your expectation is right, but as of now, Postgres-XC is not so intelligent
to understand that it can get the data from the node, which is up and thus
choose the node which is running over the one which is shut down. In your
case, it mostly chooses the node which is shut down thus giving the error.

I think it will be a good feature to have.

Regarding your question related to shutting down a server without
disturbing rest of the cluster - As of now, Postgres-XC is not dynamic, in
the sense, we can not add or remove nodes at will, neither can we boot or
shut them down at will. That's something on the list of desirable feature.

On Wed, Jan 4, 2012 at 7:17 PM, Magorn <ma...@gm...> wrote:

> Hi,
>
> I have question about Postgres-XC. I have test it with 2 node, i create
> "distribute by replication" table. I do some insert.
> I do SELECT and i see all my records. That's fine :)
>
> Next i shutdown one datanode, and i do SELECT that it fail with error :
> ERROR:  Failed to get pooled connections .
>
> Is it normal ? And if is it, when cluster have a lot of node, how stop
> some node for changer server for example without bloc all the cluser ?
>
> Perhaps i miss something about feature of postgres-xc.
>
> Regards,
>
> --
> Magorn
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

Hi,

I have question about Postgres-XC. I have test it with 2 node, i create
"distribute by replication" table. I do some insert.
I do SELECT and i see all my records. That's fine :)

Next i shutdown one datanode, and i do SELECT that it fail with error :
ERROR:  Failed to get pooled connections .

Is it normal ? And if is it, when cluster have a lot of node, how stop some
node for changer server for example without bloc all the cluser ?

Perhaps i miss something about feature of postgres-xc.

Regards,

-- 
Magorn