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

This is what we're thinking about.   XC binary to work in two
different modes, standalone and cluster mode.   The former should be
upward-compatible with PG and the latter provides cluster
configuration with scaling.

Maybe we can discuss future roadmap and development in the next PGCon
face to face.

Regards;
---
Koichi Suzuki


2014-01-30 David E. Wheeler <da...@ju...>:
> On Jan 28, 2014, at 11:00 PM, Ashutosh Bapat <ash...@en...> wrote:
>
>> I like this idea. I think, at least for few versions of XC, we will have some differences between PG and XC. But eventually, XC would declare two version numbers XC version and PG version it's based on. In such case, it would be expected that all the PG feature corresponding to that PG version would be in corresponding XC version. Even now XC declares these two things, but not necessarily everything in PG is supported. The list of unsupported features/limitations is declared in the release notes.
>
> Do you anticipate XC being binary compatible with PG at some point? Will a PostGIS compiled against Postgres 10.1 just work against PGXC 2.0?
>
> Best,
>
> David
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Thanks Michael for the prompt reply.

Year, utility command should be those handled by utility.c, almost all
the DDL statements.

As to temporary objects in implicit 2PC, this can be a candidate for 1.3.

Regards;
---
Koichi Suzuki


2014-01-30 David E. Wheeler <da...@ju...>:
> On Jan 28, 2014, at 9:42 PM, Michael Paquier <mic...@gm...> wrote:
>
>> Stuff that goes through utility.c.
>
> Okay, so then is there some way the error message can be rephrased so one can tell what sorts of commands those are?
>
> Thanks,
>
> David
>

On Jan 28, 2014, at 11:00 PM, Ashutosh Bapat <ash...@en...> wrote:

> I like this idea. I think, at least for few versions of XC, we will have some differences between PG and XC. But eventually, XC would declare two version numbers XC version and PG version it's based on. In such case, it would be expected that all the PG feature corresponding to that PG version would be in corresponding XC version. Even now XC declares these two things, but not necessarily everything in PG is supported. The list of unsupported features/limitations is declared in the release notes.

Do you anticipate XC being binary compatible with PG at some point? Will a PostGIS compiled against Postgres 10.1 just work against PGXC 2.0?

Best,

David

On Jan 28, 2014, at 9:42 PM, Michael Paquier <mic...@gm...> wrote:

> Stuff that goes through utility.c.

Okay, so then is there some way the error message can be rephrased so one can tell what sorts of commands those are?

Thanks,

David

On Wed, Jan 29, 2014 at 3:49 AM, David E. Wheeler <da...@ju...>wrote:

> Hi Mason,
>
> On Jan 28, 2014, at 1:28 PM, Mason Sharp <ms...@tr...> wrote:
>
> > Let me know what you have in mind. Are you interested in maintaining the
> XC RPMs?
>
> I'm interested in helping to make XC RPMs available in exactly the same
> way as PostgreSQL RPMs are provided by yum.postgresql.org, which would
> also allow RPMs to be created for extensions built against XC. I don't want
> to do all the maintenance myself, but would be happy to work with you and
> the PGRPMs guys going forward.
>
> The main question would be how to name things. PGRPMs attaches the major
> version number to all RPMs built against it. So you have postgresql93, of
> course, but then also postgis93, pgtap93, etc. This is so that they can
> have multiple versions at the same time, without conflict. So there is also
> postgressql92 with postgis92 and pgtap92 built against it.
>
> I don't think it would make sense to have postgresxc11 and then postgis11
> and pgtap11, because what if there was eventually an XC 9.3? What would the
> postgis and pgtap extensions built against it be called? I do think it
> makes sense to append "xc11" instead of "11", so we'd have postgresxc11,
> postgisxc11, and pgtapxc11. Thoughts?
>

I like this idea. I think, at least for few versions of XC, we will have
some differences between PG and XC. But eventually, XC would declare two
version numbers XC version and PG version it's based on. In such case, it
would be expected that all the PG feature corresponding to that PG version
would be in corresponding XC version. Even now XC declares these two
things, but not necessarily everything in PG is supported. The list of
unsupported features/limitations is declared in the release notes.


>
> > Also, are you using XC in production? Dev/test?
>
> I built these RPMs (not knowing you had already done it) in order to
> simplify things for a four-server test configuration I'm building. But also
> because I expect the test to go well, in which case we will be looking at
> building reporting and/or analytics clusters on XC in the next six months.
> I expect to ask many ignorant questions in the next few weeks. :-)
>
> Best,
>
> David
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

On Wed, Jan 29, 2014 at 1:03 PM, David E. Wheeler <da...@ju...> wrote:
> On Jan 28, 2014, at 8:00 PM, Koichi Suzuki <koi...@gm...> wrote:
>
>> Yes, utility statements are not allowed in functions and you cannot
>> use temporary object if more than one node are involved in a
>> transaction.
>
> So:
>
> 1. What is a utility statement?
Stuff that goes through utility.c.
-- 
Michael

On Wed, Jan 29, 2014 at 1:00 PM, Koichi Suzuki <koi...@gm...> wrote:
> Yes, utility statements are not allowed in functions and you cannot
> use temporary object if more than one node are involved in a
> transaction.
>
> The former may be fixed.   Michael, do you have any mention to this
> restriction that utility statements are not allowed in functions?
If I recall correctly, this limitation is caused by ruleutils.c for
query rebuilding.
Regards,
-- 
Michael

On Jan 28, 2014, at 8:00 PM, Koichi Suzuki <koi...@gm...> wrote:

> Yes, utility statements are not allowed in functions and you cannot
> use temporary object if more than one node are involved in a
> transaction.

So:

1. What is a utility statement?
2. How does one limit the nodes on which something executes?

> The background of the latter is the implicit 2PC.   You can set
> enforce_two_phase_commit to OFF to use temporary object but this may
> come up with data inconsistency among the nodes.   I believe we can
> allow temporary objects in such a transaction because temporary
> objects don't have to survive beyond the session.   As long as only
> implicit 2PCs are involved, we may be able to allow temporary objects
> and can extend current XC core.

Yeah, I only need a temporary table on the node on which stuff is executing, if that makes sense. Basically, for pgTAP tests, a transaction is started, temporary tables are created to store the test state, then the tests run, the state is shown to the user, and then the temporary tables are dropped (or allowed to disappear on disconnect).

Thanks,

David

Yes, utility statements are not allowed in functions and you cannot
use temporary object if more than one node are involved in a
transaction.

The former may be fixed.   Michael, do you have any mention to this
restriction that utility statements are not allowed in functions?

The background of the latter is the implicit 2PC.   You can set
enforce_two_phase_commit to OFF to use temporary object but this may
come up with data inconsistency among the nodes.   I believe we can
allow temporary objects in such a transaction because temporary
objects don't have to survive beyond the session.   As long as only
implicit 2PCs are involved, we may be able to allow temporary objects
and can extend current XC core.

Regards;
---
Koichi Suzuki


2014-01-29 David E. Wheeler <da...@ju...>:
> XCers,
>
> I just tried to use pgTAP on XC and got this error:
>
>    dwheeler=# create extension pgtap;
>    ERROR:  In XC, SQL functions cannot contain utility statements
>    CONTEXT:  SQL function "_cleanup"
>
> This is _cleanup():
>
>    CREATE OR REPLACE FUNCTION _cleanup()
>    RETURNS boolean AS $$
>        DROP TABLE __tresults__;
>        DROP SEQUENCE __tresults___numb_seq;
>        DROP TABLE __tcache__;
>        DROP SEQUENCE __tcache___id_seq;
>        SELECT TRUE;
>    $$ LANGUAGE sql;
>
> These are temporary objects created by an EXECUTE statement in another function. Are they disallowed?
>
> Google just turned up the XC source:
>
>  https://github.com/postgres-xc/postgres-xc/blob/master/src/backend/catalog/pg_proc.c#L897
>
> Maybe those errors should be re-worded to indicate *what* utility statements are disallowed. Happy to contribute a patch if someone can list them.
>
> Otherwise, I would be interested to figure out how I could work around this issue on XC.
>
> Thanks,
>
> David
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

XCers,

I was trying to diagnose this issue:

    psql --set ON_ERROR_ROLLBACK=1 --set ON_ERROR_STOP=1 --file pg.sql
    psql:pg.sql:3: ERROR:  SAVEPOINT is not yet supported.

The first three lines are:

    BEGIN;

    SET client_min_messages = warning;
    CREATE SCHEMA sqitch;

I had thought that it was the CREATE SCHEMA statement it was complaining about, so I tried this:

    psql -d repcluster --set ON_ERROR_ROLLBACK=1 -c 'BEGIN; CREATE SCHEMA foo; COMMIT;'
    ERROR:  Failed to PREPARE the transaction on one or more nodes

So that's annoying. So I tired it again:

    psql --set ON_ERROR_ROLLBACK=1 -c 'BEGIN; CREATE SCHEMA foo; COMMIT;'
    ERROR:  schema "foo" already exists

That’s not good. I looked at all my nodes, four coordinators and four data nodes, and the schema is present in all but one, that one being the coordinator I actually ran the statement against.

I thought that was not possible. So how do I fix this? I can't drop it, because it doesn't exist on that one coordinator. I can't even drop it if I connect to another coordinator. And I can't create it, either, since it already exists in 7 out of the 8 places it ought to. :-(

Meanwhile, What part of my original file does XC think is a SAVEPOINT? Is it the SET statement?

Thanks,

David

XCers,

I just tried to use pgTAP on XC and got this error:

   dwheeler=# create extension pgtap;
   ERROR:  In XC, SQL functions cannot contain utility statements
   CONTEXT:  SQL function "_cleanup"

This is _cleanup():

   CREATE OR REPLACE FUNCTION _cleanup()
   RETURNS boolean AS $$
       DROP TABLE __tresults__;
       DROP SEQUENCE __tresults___numb_seq;
       DROP TABLE __tcache__;
       DROP SEQUENCE __tcache___id_seq;
       SELECT TRUE;
   $$ LANGUAGE sql;

These are temporary objects created by an EXECUTE statement in another function. Are they disallowed?

Google just turned up the XC source:

 https://github.com/postgres-xc/postgres-xc/blob/master/src/backend/catalog/pg_proc.c#L897

Maybe those errors should be re-worded to indicate *what* utility statements are disallowed. Happy to contribute a patch if someone can list them.

Otherwise, I would be interested to figure out how I could work around this issue on XC.

Thanks,

David

Hi Mason,

On Jan 28, 2014, at 1:28 PM, Mason Sharp <ms...@tr...> wrote:

> Let me know what you have in mind. Are you interested in maintaining the XC RPMs?

I’m interested in helping to make XC RPMs available in exactly the same way as PostgreSQL RPMs are provided by yum.postgresql.org, which would also allow RPMs to be created for extensions built against XC. I don't want to do all the maintenance myself, but would be happy to work with you and the PGRPMs guys going forward.

The main question would be how to name things. PGRPMs attaches the major version number to all RPMs built against it. So you have postgresql93, of course, but then also postgis93, pgtap93, etc. This is so that they can have multiple versions at the same time, without conflict. So there is also postgressql92 with postgis92 and pgtap92 built against it.

I don't think it would make sense to have postgresxc11 and then postgis11 and pgtap11, because what if there was eventually an XC 9.3? What would the postgis and pgtap extensions built against it be called? I do think it makes sense to append “xc11” instead of “11”, so we’d have postgresxc11, postgisxc11, and pgtapxc11. Thoughts?

> Also, are you using XC in production? Dev/test?

I built these RPMs (not knowing you had already done it) in order to simplify things for a four-server test configuration I’m building. But also because I expect the test to go well, in which case we will be looking at building reporting and/or analytics clusters on XC in the next six months. I expect to ask many ignorant questions in the next few weeks. :-)

Best,

David

Hi David,


On Tuesday, January 28, 2014, David E. Wheeler
<da...@ju...<javascript:_e({}, 'cvml',
'da...@ju...');>>
wrote:

> On Jan 27, 2014, at 6:13 PM, Koichi Suzuki <koi...@gm...> wrote:
>
> > The source of the doc has everything.    Some descriptions about
> > non-supported features such as FDW are sgtripped from XC docs.
> >
> > It is very simple to get them back though.
>
> Okay. I'm pretty happy with the RPMs I've created now. Perhaps Mason,
> Devrim, and I should put our heads together to decide what to do next, yes?
>
>
Let me know what you have in mind. Are you interested in maintaining the XC
RPMs?

Also, are you using XC in production? Dev/test?

Thanks,

Mason


> Best,
>
> David
>
>
>

>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>


-- 
Mason Sharp

TransLattice - http://www.translattice.com
Distributed and Clustered Database Solutions

On Jan 27, 2014, at 6:13 PM, Koichi Suzuki <koi...@gm...> wrote:

> The source of the doc has everything.    Some descriptions about
> non-supported features such as FDW are sgtripped from XC docs.
> 
> It is very simple to get them back though.

Okay. I’m pretty happy with the RPMs I’ve created now. Perhaps Mason, Devrim, and I should put our heads together to decide what to do next, yes?

Best,

David

Sorry for the late response.
---
Koichi Suzuki


2014-01-25 ZhangJulian <jul...@ou...>:
> Hi All,
>
> I am thinking 3 choices as below:
>
> 1. Pacemaker and Corosync.
> I have little experience on Linux HA, so one week passed, I even can not
> install them successfully, including Pacemaker/Corosync/crmsh/resouce agent.
> There are some website mentioned Pacemaker/corosync can help PGXC to build a
> HA infrastructure, but I can not find a comprehensive guide to do it. There
> are much more commponents in PGXC than PG, I think I should learn how to
> build it based on PG first.

I know separate XC project to provide Pacemaker/Corosync resource
agent for XC.   Please let me push them to provide info.

>
> 2. Zookeeper
> It seems that Zookeeper has the ability to build a HA solution for PGXC,
> which have the similar function with Pacemaker, but I have to develop the
> heartbeat function for Zookeeper to start/stop/monitor/failover PGXC. And I
> do not know if my understand is right.

Sorry, I'm not familiar with Zookeeper.

>
> 3. PGXC support HA internally.
> Because the table of pgxc_nodes in coordinator already have some information
> about the cluster, it can be enhanced to save the Master/Slave relations, it
> is replicated between all coordinators, then it can used as a CRM(Cluster
> Resource Management, as Pacemaker) compoment.
> And the coordinator will connect to datanode/gtm/other coordinator in its
> regular work, so the heartbeat function exists natually. Even when the
> database is in the spare time, the coordinator can send a simple query as
> "select 1+1" to datanodes as the heartbeat ticks.
> What need to do is that, the coordinator will start a new process when
> starting, the new process will act as a heartbeat /resouce_agent to monitor
> the cluster status, and restart/failover once one commponent fails.
>
> As my initial understanding, Choice 3 is better than Choice 2 which is
> better than Choice 1. But for the development effort, the order is reversed,
> Choice 1 is easy achieved based on current existing codes.
>
> I am very appreciated that you can share your advice with me.

Yes, I do agree with this solution.   I'd like to have this as a part
of XC release 1.3.

PGXC internal HA should be integrated with other monitoring feature
such as server hardware, power and network.

It will be exciting to begin this discussion in this mailing list.

Regards;
---
Koichi Suzuki

>
> Thanks
> Julian
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

2014-01-25 David E. Wheeler <da...@ju...>:
> On Jan 24, 2014, at 12:24 AM, Michael Meskes <me...@po...> wrote:
>
>> We haven't completely solved the coexistance part yet, but mainly due to time
>> constraints. What we do so far is only build those pieces of XC that are
>> different and rely on the PG packages for the rest.
>
> Really? You actually have RPMs that depend on Postgres, and add the XC functionality in a binary distribution?
>
>> As for the docs, I remember the clean target not removing the generated SGML
>> files. However, we do have the specific manpages in place and I do not remember
>> them needing any special treatment. But then I may have simply forgotton about
>> that one.
>
> I just didn't realize they were in doc-xc instead of doc.
>
>>> I need to maintain corresponding PG docs for work and for merge
>>> process, it's convenient to have XC docs in a different directory.
>>> Do you think original PG docs should not be a part of XC release?
>>
>> I think they have to be part of it. After all people might just install XC
>> without PG alongside it.
>
> But the XC docs include everything from the pg docs, no?

The source of the doc has everything.    Some descriptions about
non-supported features such as FDW are sgtripped from XC docs.

It is very simple to get them back though.

Internals of XC documentation will be found at
http://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Reference_Manual

Regards;
---
Koichi Suzuki

>
> Best,
>
> David
>
>

On Jan 27, 2014, at 2:12 PM, Devrim GÜNDÜZ <de...@gu...> wrote:

>> Right. libpq should be included in your -libs package or something,
>> right? psql won't work without it.
> 
> Yeah. This is what we do with the RPMs (I know that Debian folks have a
> separate package for this, as Michael wrote)

And I ported your Spec file, so in my RPMs libpq is included in the -libs RPM.

D

Hi,

On Sat, 2014-01-25 at 15:10 -0800, David E. Wheeler wrote:
> Right. libpq should be included in your -libs package or something,
> right? psql won't work without it.

Yeah. This is what we do with the RPMs (I know that Debian folks have a
separate package for this, as Michael wrote)

Regards,
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

http://sourceforge.net/mailarchive/forum.php?thread_name=BLU179-W70289FBF366F7EED90656CA5A00%40phx.gbl&forum_name=postgres-xc-developers

Anybody had reveived this mail? I send it out but hadn't received it in mailbox as expected. 



 		 	   		  

On Jan 25, 2014, at 5:30 PM, Michael Paquier <mic...@gm...> wrote:

> There is already an XC group in github, would it make sense to move
> those RPM specs there?
> https://github.com/postgres-xc

It’s okay with me, but if Mason has already done the work, there probably isn’t much for me to merge. Happy to start with his.

Best,

David

On Jan 26, 2014, at 5:11 AM, Michael Meskes <me...@po...> wrote:

> We actually have libpq in a package of its own. 

I see. Doesn’t look like the StormDB RPMs do. They appear to be pretty similar to what I created.

  http://yum.stormdb.com/repos/Postgres-XC/1.1.0/centos64/

Best,

David

On Sat, Jan 25, 2014 at 03:10:09PM -0800, David E. Wheeler wrote:
> Right. libpq should be included in your -libs package or something, right? psql won't work without it.

We actually have libpq in a package of its own. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Fri, Jan 24, 2014 at 9:45 AM, David E. Wheeler <da...@ju...> wrote:
>   https://github.com/theory/postgres-xc-rpm/commit/5a7b7cb3e735e8b8faf99ad6081e72cf7f790dde
There is already an XC group in github, would it make sense to move
those RPM specs there?
https://github.com/postgres-xc
Regards,
-- 
Michael

On Jan 25, 2014, at 2:13 AM, Michael Meskes <me...@po...> wrote:

>> Really? You actually have RPMs that depend on Postgres, and add the XC functionality in a binary distribution?
> 
> No. First of all we have DEBs no RPMs. And second of all, what I was meaning to say it we have for instance a Postgres-XC server package, because that is different from PostgreSQL. But we do not have an XC libpq package.

Right. libpq should be included in your -libs package or something, right? psql won't work without it.

>> But the XC docs include everything from the pg docs, no?
> 
> Yes, afaict.

That’s what I thought.

Thanks,

David

On Fri, Jan 24, 2014 at 02:17:13PM -0800, David E. Wheeler wrote:
> > We haven't completely solved the coexistance part yet, but mainly due to time
> > constraints. What we do so far is only build those pieces of XC that are
> > different and rely on the PG packages for the rest.
> 
> Really? You actually have RPMs that depend on Postgres, and add the XC functionality in a binary distribution?

No. First of all we have DEBs no RPMs. And second of all, what I was meaning to say it we have for instance a Postgres-XC server package, because that is different from PostgreSQL. But we do not have an XC libpq package.

> > I think they have to be part of it. After all people might just install XC
> > without PG alongside it.
> 
> But the XC docs include everything from the pg docs, no?

Yes, afaict.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL