From: David E. W. <da...@ju...> - 2014-01-21 21:47:09
|
Postgres-XCers, I forked Devrim’s RPM spec file for Postgres 9.3 on EL-6 and started on building RPMs for XC. You can see my progress here: https://github.com/theory/postgres-xc-rpm It successfully builds these RPMs: * postgresxc11-docs-1.1.0 * postgresxc11-contrib-1.1.0 * postgresxc11-plperl-1.1.0 * postgresxc11-server-1.1.0 * postgresxc11-pltcl-1.1.0 * postgresxc11-debuginfo-1.1.0 * postgresxc11-devel-1.1.0 * postgresxc11-test-1.1.0 * postgresxc11-1.1.0 * postgresxc11-libs-1.1.0 * postgresxc11-plpython-1.1.0 Not bad, right? However, I have a few questions and suggestions about things I’ve found: * I suggest using the version in the decompressed directory prefix. The tarball is called “pgxc-v1.1.tar.gz”, but decompresses into a directory named “postgres-xc”. I think these should be the same. In other words, the the directory should be named “pgxc-v1.1”. Or, if you wanted things to be closer to what Postgres and other projects do, maybe call the tarball “postgres-xc-1.1.tar.gz” and the directory “postgres-xc-1.1”. Or maybe “postgresxc-1.1.tar.gz” and the directory “postgresxc-1.1”. Thoughts? * I’m using “postgresxc” for the RPM name. This keeps it more or less in line with the Postgres core, which uses “postgresql”. Make sense to you? Or is the hyphen strongly preferred? * I’m building with the directory path /usr/pgxc-1.1 instead of /usr/pgsql-1.1 (or /usr/pgsql-9.2). I think it would be reasonable for the default to use “pgxc” instead of “pgsql”, again, to keep the two things distinct. Thoughts? * In that vein, it would be useful to allow “pgxc” in the directory path. I refer to the “NOTE” just below the docs for --htmldir here: http://postgres-xc.sourceforge.net/docs/1_1/install-procedure.html It says: > First, the string "/postgresql" is automatically appended to datadir, sysconfdir, and docdir, unless the fully expanded directory name already contains the string "postgres" or "pgsql" I suggest appending “or pgxc” to that list. Here’s a patch for that: https://github.com/theory/postgres-xc-rpm/blob/master/SOURCES/rpm-pgxc.patch (Though that patch also replaces “/postgresql” with “/pgxc”, which you might not want. Maybe it should be “/postgrexc”?) * Have you considered building the docs before shipping? Most folks don’t have jade installed, so I think the Postgres core guys build the docs before taring up the release. For the RPM I'm just building them, so no biggie there, but I doubt I’d ever build them on my Mac. * Finally, does the pgxc community have an interest in hosting a Yum repository the way pgrpms does? Or should I just try to get it into pgrpms and see what happens? It might be more complicated than they want, since they build all the other stuff around each version of Postgres. So you can install postgres92 or postgres93, and if you want PostGIS, you install the corresponding postgis92 or postgis93. Not sure how that would be handled for XC. I mean, it would be postgis11, but eventually there might be overlap in the version, right? Will be starting an experiment with XC over the next few weeks, so I expect to have more questions, though probably fewer about packaging from here on in. :-) Thanks, David |
From: David E. W. <da...@ju...> - 2014-01-22 00:02:23
|
On Jan 21, 2014, at 1:30 PM, David E. Wheeler <da...@ju...> wrote: > * Have you considered building the docs before shipping? Most folks don’t have jade installed, so I think the Postgres core guys build the docs before taring up the release. For the RPM I'm just building them, so no biggie there, but I doubt I’d ever build them on my Mac. Oh, BTW, this does not appear to generate the man pages for the XC-specific stuff. For example, there are no gtm.1, gtm_proxy.1, initgtm.1, or gtm_ctl.1 files in share/man/man1/. Also, should there be man pages in share/man/man3/ for XC-speific commands? Best, David |
From: Koichi S. <koi...@gm...> - 2014-01-23 02:17:02
|
Hello David; Thank you very much for the effort and sorry for the late response. I agree on your points. Yes, as PG, tarball directory should be postgres-xc-1.1 or so. Please let me change this in the following releases. As per documents, release tarballs include html and man. Which is in doc-xc/src/sgml, not in doc. They all comes with XC-specific stuff as well as differences as you found in XC pages. The location of docs is not described clearly in the notes, which need to improve. We should consider the target installation directory especially when XC coexists with PG. Michael Meskes had similar problem in XC packaging for Debian and I hope he has some experience and ideas on this. 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? On the other hand I'm worrying is Mason Sharp has already published his rpms for linux 64bit and 32bit at his stormDB page. I don't know how long he can continue this work and it will be nice if you visit his page and see how we can work together. Please understand I highly appreciate for efforts of XC packaging, which is a great help for XC deployment. Mason, any more inputs? Regards; --- Koichi Suzuki 2014/1/22 David E. Wheeler <da...@ju...>: > On Jan 21, 2014, at 1:30 PM, David E. Wheeler <da...@ju...> wrote: > >> * Have you considered building the docs before shipping? Most folks don’t have jade installed, so I think the Postgres core guys build the docs before taring up the release. For the RPM I'm just building them, so no biggie there, but I doubt I’d ever build them on my Mac. > > Oh, BTW, this does not appear to generate the man pages for the XC-specific stuff. For example, there are no gtm.1, gtm_proxy.1, initgtm.1, or gtm_ctl.1 files in share/man/man1/. Also, should there be man pages in share/man/man3/ for XC-speific commands? > > Best, > > David > > > ------------------------------------------------------------------------------ > 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 |
From: Michael M. <me...@po...> - 2014-01-24 08:24:19
|
On Thu, Jan 23, 2014 at 11:16:54AM +0900, Koichi Suzuki wrote: > We should consider the target installation directory especially when > XC coexists with PG. Michael Meskes had similar problem in XC > packaging for Debian and I hope he has some experience and ideas on > this. 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. 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 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. 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 |
From: David E. W. <da...@ju...> - 2014-01-24 22:17:35
|
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? Best, David |
From: Michael M. <me...@po...> - 2014-01-25 10:13:46
|
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 |
From: David E. W. <da...@ju...> - 2014-01-23 17:28:59
|
On Jan 22, 2014, at 6:16 PM, Koichi Suzuki <koi...@gm...> wrote: > Thank you very much for the effort and sorry for the late response. > I agree on your points. Yes, as PG, tarball directory should be > postgres-xc-1.1 or so. Please let me change this in the following > releases. I also suggest you make it 1.1.0 in the future, so that the format is the same if you later release 1.1.1. > As per documents, release tarballs include html and man. Which is in > doc-xc/src/sgml, not in doc. They all comes with XC-specific stuff > as well as differences as you found in XC pages. The location of > docs is not described clearly in the notes, which need to improve. Ahhhh! There they are! I will fix the spec file today. > We should consider the target installation directory especially when > XC coexists with PG. Michael Meskes had similar problem in XC > packaging for Debian and I hope he has some experience and ideas on > this. I’ve been chatting with Jeff Frost and Devrim GÜNDÜZ about it, too. Devrim seems to think that there should be a separate XC yum repo, perhaps under the postgres-xc.com domain. > 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? No, if the XC docs are a superset of the PG docs, then you don't need to build and ship the PG docs. Might make sense to not ship their SGML at all. Maybe `rm -rf doc && mv doc-xc doc`. > On the other hand I'm worrying is Mason Sharp has already published > his rpms for linux 64bit and 32bit at his stormDB page. I don't > know how long he can continue this work and it will be nice if you > visit his page and see how we can work together. Ah-ha! I was not aware of this. Seems like quite a bit of overlap. http://yum.stormdb.com/repos/Postgres-XC/1.1.0/centos64/ > Please understand I highly appreciate for efforts of XC packaging, > which is a great help for XC deployment. > > Mason, any more inputs? We should certainly collaborate to create a “community” repo, I think. Thoughts? BTW, I also created a separate gtm RPM. https://github.com/theory/postgres-xc-rpm/commit/f94354a0365f15fa6850d24024bb5a59d2b202d8 Best, David |
From: Koichi S. <koi...@gm...> - 2014-01-24 01:48:02
|
Hi, 2014/1/24 David E. Wheeler <da...@ju...>: > On Jan 22, 2014, at 6:16 PM, Koichi Suzuki <koi...@gm...> wrote: > >> Thank you very much for the effort and sorry for the late response. >> I agree on your points. Yes, as PG, tarball directory should be >> postgres-xc-1.1 or so. Please let me change this in the following >> releases. > > I also suggest you make it 1.1.0 in the future, so that the format is the same if you later release 1.1.1. > >> As per documents, release tarballs include html and man. Which is in >> doc-xc/src/sgml, not in doc. They all comes with XC-specific stuff >> as well as differences as you found in XC pages. The location of >> docs is not described clearly in the notes, which need to improve. > > Ahhhh! There they are! I will fix the spec file today. > >> We should consider the target installation directory especially when >> XC coexists with PG. Michael Meskes had similar problem in XC >> packaging for Debian and I hope he has some experience and ideas on >> this. > > I’ve been chatting with Jeff Frost and Devrim GÜNDÜZ about it, too. Devrim seems to think that there should be a separate XC yum repo, perhaps under the postgres-xc.com domain. Are you suggesting to have separate site as yum (and could be deb) repo for XC? It will be nice if somebody can help this and to move current XC pages (now in sourceforge wiki) to a separate place. Now current active members are fully booked in development, test and fixes. I appreciate for any of such help. > >> 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? > > No, if the XC docs are a superset of the PG docs, then you don't need to build and ship the PG docs. Might make sense to not ship their SGML at all. Maybe `rm -rf doc && mv doc-xc doc`. Okay. As you have noticed, XC doc comes with the note which is the same as PG and which is different in XC. In this sense, XC doc is a superset of PG docs. > >> On the other hand I'm worrying is Mason Sharp has already published >> his rpms for linux 64bit and 32bit at his stormDB page. I don't >> know how long he can continue this work and it will be nice if you >> visit his page and see how we can work together. > > Ah-ha! I was not aware of this. Seems like quite a bit of overlap. > > http://yum.stormdb.com/repos/Postgres-XC/1.1.0/centos64/ > >> Please understand I highly appreciate for efforts of XC packaging, >> which is a great help for XC deployment. >> >> Mason, any more inputs? > > We should certainly collaborate to create a “community” repo, I think. Thoughts? I believe it is a good idea to collect each effort. In this case, yes you could collaborate with Mason. Could you launch this discussion in "general" or "developers" mailing list? > > BTW, I also created a separate gtm RPM. > > https://github.com/theory/postgres-xc-rpm/commit/f94354a0365f15fa6850d24024bb5a59d2b202d8 > > Best, > > David > Thank you; --- Koichi Suzuki |
From: David E. W. <da...@ju...> - 2014-01-24 00:45:38
|
On Jan 23, 2014, at 9:28 AM, David E. Wheeler <da...@ju...> wrote: > Ahhhh! There they are! I will fix the spec file today. Done. https://github.com/theory/postgres-xc-rpm/commit/5a7b7cb3e735e8b8faf99ad6081e72cf7f790dde Best, David |
From: David E. W. <da...@ju...> - 2014-01-25 23:10:29
|
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 |
From: Michael P. <mic...@gm...> - 2014-01-26 01:30:13
|
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 |
From: David E. W. <da...@ju...> - 2014-01-27 04:08:29
|
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 |
From: Michael M. <me...@po...> - 2014-01-26 13:11:19
|
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 |
From: David E. W. <da...@ju...> - 2014-01-27 04:07:08
|
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 |
From: Devrim G. <de...@gu...> - 2014-01-27 22:31:21
Attachments:
signature.asc
|
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 |
From: David E. W. <da...@ju...> - 2014-01-28 00:14:47
|
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 |
From: Koichi S. <koi...@gm...> - 2014-01-28 02:13:37
|
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 > > |
From: David E. W. <da...@ju...> - 2014-01-28 16:38:11
|
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 |
From: Mason S. <ms...@tr...> - 2014-01-28 21:37:03
|
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 |
From: David E. W. <da...@ju...> - 2014-01-28 22:19:21
|
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 |
From: Ashutosh B. <ash...@en...> - 2014-01-29 07:00:14
|
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 |
From: David E. W. <da...@ju...> - 2014-01-29 16:58:07
|
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 |
From: Koichi S. <koi...@gm...> - 2014-01-30 01:11:58
|
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 |
From: Ashutosh B. <ash...@en...> - 2014-01-30 07:14:09
|
On Wed, Jan 29, 2014 at 10:27 PM, David E. Wheeler <da...@ju...>wrote: > 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? > > Hmm, It depends what APIs in Postgres are being used in PostGIS. We have modified a quite a few internal functions and structures e.g. standard_ProcessUtility() to work in cluster environment. Using those functions would break the object linkages. But anything which is SQL compatible with 10.1 will work against PGXC 2.0 if we get to catch up with PG by then. One may not need to modify the code in such cases, but would require to build the extension or binary again. > Best, > > David -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company |
From: David E. W. <da...@ju...> - 2014-01-30 17:54:37
|
On Jan 29, 2014, at 11:14 PM, Ashutosh Bapat <ash...@en...> wrote: > It depends what APIs in Postgres are being used in PostGIS. We have modified a quite a few internal functions and structures e.g. standard_ProcessUtility() to work in cluster environment. Using those functions would break the object linkages. But anything which is SQL compatible with 10.1 will work against PGXC 2.0 if we get to catch up with PG by then. One may not need to modify the code in such cases, but would require to build the extension or binary again. Well, that seems a rather long way off, and RPMs can be renamed at that time, if appropriate. In the meantime, I think using the "xc11" suffix as I proposed is the way to go. Agreed? Best, David |