Menu
▾
▴
postgres-xc-bugs — Bug report
You can subscribe to this list here.
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(7) |
May
(27) |
Jun
(15) |
Jul
(11) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(10) |
Oct
(19) |
Nov
(34) |
Dec
(6) |
| 2014 |
Jan
(31) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(6) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
(9) |
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: West, W. <ww...@uc...> - 2013-11-01 17:56:31
|
All, I have a database set up but it seems fairly unstable. I have a number of objects in the running database but I have one object that is corrupt. I know this because doing any query or dml statement on this table stalls the client. I also notice that when I run statements that encounter the invalid object. It spawns 2 process ID like below: 505149 19373 0.0 0.0 191768 5908 ? Ss 10:30 0:00 postgres: postgresql bigonc [local] VACUUM 505149 19379 1.2 0.0 191972 24776 ? Ss 10:30 0:00 postgres: postgresql bigonc 127.0.0.1(46305) VACUUM waiting These processes never complete and seem like they are locking one another. However there is nothing showing in pg_locks. Does anyone recognize this behavior. Is there anyway to repair or drop a corrupt object in the database? Thanks, Bill West |
|
From: West, W. <ww...@uc...> - 2013-11-01 17:41:16
|
All, I have a database set up but it seems fairly unstable. I have a number of objects in the running database but I have one object that is corrupt. I know this because doing any query or dml statement on this table stalls the client. I also notice that when I run statements that encounter the invalid object. It spawns 2 process ID like below: 505149 19373 0.0 0.0 191768 5908 ? Ss 10:30 0:00 postgres: postgresql bigonc [local] VACUUM 505149 19379 1.2 0.0 191972 24776 ? Ss 10:30 0:00 postgres: postgresql bigonc 127.0.0.1(46305) VACUUM waiting These processes never complete and seem like they are locking on another. However there is nothing showing in pg_locks. Does anyone recognize this behavior. Is there anyway to repair or drop a corrupt object in the database? Thanks, Bill West |
|
From: DIMI <nic...@un...> - 2013-10-31 19:14:50
|
I confirm that Nikhil’s suggestion works without patching! Nicola On 31/ott/2013, at 16:30, Koichi Suzuki <koi...@gm...> wrote: > Thanks Nikhil. We may need a way to set it up automatically via ./configure. > > Nicola, could you test this? This CFLAGS setting may disable -O2 optimization so it would be better to add this. > > Regards; > > --- > Koichi Suzuki > > > 2013/10/31 Nikhil Sontakke <ni...@st...> > Hi Nicola, Suzuki-san, > > IMO, no patch is needed for XC compilation on latest OS X. > > Please append this to the CFLAGS: "-D_FORTIFY_SOURCE=0" and it should compile ok on Maverick. > > ./configure CFLAGS="-D_FORTIFY_SOURCE=0" > > Did work for me. > > Regards, > Nikhils > > > > On Thu, Oct 31, 2013 at 11:42 AM, DIMI <nic...@un...> wrote: > Please find enclosed the output of ./configure. I don’t see anything apparently wrong. > > I’d be happy to contribute supporting XC on OS X, although I don’t have much familiarity with the code. Should I subscribe to some developer mailing list? > > Nicola > > > > > On 31/ott/2013, at 03:08, Koichi Suzuki <koi...@gm...> wrote: > >> I'm interested if ./configure is successful. >> >> Maybe the patch Michael suggested may not be sufficient. I suspect there's another problem in ./configure. If you allow me some time (maybe some time next week) until I upgrade my Macs to Marberics, I can reproduce the problem. >> >> Please understand that XC has not announced OS X support so far because we don't have sufficient resource. It will be nice if you help to support XC on OS X, or any other platforms other than Intel Linux. >> >> Regards; >> >> --- >> Koichi Suzuki >> >> >> 2013/10/30 DIMI <nic...@un...> >> Thanks, the patch can now be applied. But, it doesn’t fix the problem: I still get the same build errors. >> >> Nicola >> >> On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: >> >>> Because the patch is for vanilla PG. Sometimes we have patch conflict. Here's a hack of the patch. Because the nature of the patch does not have any bad influence, I hope you can try this. Please let me know how it works. >>> >>> # Please understand that this is really a quick hack and I'm not tracking this patch in a good manner. >>> >>> Good Luck; >>> >>> --- >>> Koichi Suzuki >>> >>> >>> 2013/10/30 DIMI <nic...@un...> >>> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> wrote: >>> >>> > There have been fixes these days in Postgres core for Mavericks for strlcpy: >>> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >>> >>> I cannot apply that patch to Postgres-XC 1.1. And after making the change manually, I still get the same build errors. Am I missing something? >>> >>> Nicola >>> >>> >>> <tupdesc.c.patch> >> >> > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > |
|
From: Koichi S. <koi...@gm...> - 2013-10-31 15:30:42
|
Thanks Nikhil. We may need a way to set it up automatically via ./configure. Nicola, could you test this? This CFLAGS setting may disable -O2 optimization so it would be better to add this. Regards; --- Koichi Suzuki 2013/10/31 Nikhil Sontakke <ni...@st...> > Hi Nicola, Suzuki-san, > > IMO, no patch is needed for XC compilation on latest OS X. > > Please append this to the CFLAGS: "-D_FORTIFY_SOURCE=0" and it should > compile ok on Maverick. > > ./configure CFLAGS="-D_FORTIFY_SOURCE=0" > > Did work for me. > > Regards, > Nikhils > > > > On Thu, Oct 31, 2013 at 11:42 AM, DIMI <nic...@un...>wrote: > >> Please find enclosed the output of ./configure. I don’t see anything >> apparently wrong. >> >> I’d be happy to contribute supporting XC on OS X, although I don’t have >> much familiarity with the code. Should I subscribe to some developer >> mailing list? >> >> Nicola >> >> >> >> >> On 31/ott/2013, at 03:08, Koichi Suzuki <koi...@gm...> wrote: >> >> I'm interested if ./configure is successful. >> >> Maybe the patch Michael suggested may not be sufficient. I suspect >> there's another problem in ./configure. If you allow me some time (maybe >> some time next week) until I upgrade my Macs to Marberics, I can reproduce >> the problem. >> >> Please understand that XC has not announced OS X support so far because >> we don't have sufficient resource. It will be nice if you help to support >> XC on OS X, or any other platforms other than Intel Linux. >> >> Regards; >> >> --- >> Koichi Suzuki >> >> >> 2013/10/30 DIMI <nic...@un...> >> >>> Thanks, the patch can now be applied. But, it doesn’t fix the problem: I >>> still get the same build errors. >>> >>> Nicola >>> >>> On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: >>> >>> Because the patch is for vanilla PG. Sometimes we have patch conflict. >>> Here's a hack of the patch. Because the nature of the patch does not >>> have any bad influence, I hope you can try this. Please let me know how >>> it works. >>> >>> # Please understand that this is really a quick hack and I'm not >>> tracking this patch in a good manner. >>> >>> Good Luck; >>> >>> --- >>> Koichi Suzuki >>> >>> >>> 2013/10/30 DIMI <nic...@un...> >>> >>>> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> >>>> wrote: >>>> >>>> > There have been fixes these days in Postgres core for Mavericks for >>>> strlcpy: >>>> > >>>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >>>> >>>> I cannot apply that patch to Postgres-XC 1.1. And after making the >>>> change manually, I still get the same build errors. Am I missing something? >>>> >>>> Nicola >>>> >>>> >>> <tupdesc.c.patch> >>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >> >> > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > |
|
From: Nikhil S. <ni...@st...> - 2013-10-31 11:18:49
|
Hi Nicola, Suzuki-san, IMO, no patch is needed for XC compilation on latest OS X. Please append this to the CFLAGS: "-D_FORTIFY_SOURCE=0" and it should compile ok on Maverick. ./configure CFLAGS="-D_FORTIFY_SOURCE=0" Did work for me. Regards, Nikhils On Thu, Oct 31, 2013 at 11:42 AM, DIMI <nic...@un...> wrote: > Please find enclosed the output of ./configure. I don’t see anything > apparently wrong. > > I’d be happy to contribute supporting XC on OS X, although I don’t have > much familiarity with the code. Should I subscribe to some developer > mailing list? > > Nicola > > > > > On 31/ott/2013, at 03:08, Koichi Suzuki <koi...@gm...> wrote: > > I'm interested if ./configure is successful. > > Maybe the patch Michael suggested may not be sufficient. I suspect > there's another problem in ./configure. If you allow me some time (maybe > some time next week) until I upgrade my Macs to Marberics, I can reproduce > the problem. > > Please understand that XC has not announced OS X support so far because we > don't have sufficient resource. It will be nice if you help to support XC > on OS X, or any other platforms other than Intel Linux. > > Regards; > > --- > Koichi Suzuki > > > 2013/10/30 DIMI <nic...@un...> > >> Thanks, the patch can now be applied. But, it doesn’t fix the problem: I >> still get the same build errors. >> >> Nicola >> >> On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: >> >> Because the patch is for vanilla PG. Sometimes we have patch conflict. >> Here's a hack of the patch. Because the nature of the patch does not >> have any bad influence, I hope you can try this. Please let me know how >> it works. >> >> # Please understand that this is really a quick hack and I'm not tracking >> this patch in a good manner. >> >> Good Luck; >> >> --- >> Koichi Suzuki >> >> >> 2013/10/30 DIMI <nic...@un...> >> >>> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> >>> wrote: >>> >>> > There have been fixes these days in Postgres core for Mavericks for >>> strlcpy: >>> > >>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >>> >>> I cannot apply that patch to Postgres-XC 1.1. And after making the >>> change manually, I still get the same build errors. Am I missing something? >>> >>> Nicola >>> >>> >> <tupdesc.c.patch> >> >> >> > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: Koichi S. <koi...@gm...> - 2013-10-31 07:17:05
|
Thank you for your interest. Yes, you can subscribe developers and general mailing list to watch watch is going on. Regards; --- Koichi Suzuki 2013/10/31 DIMI <nic...@un...> > Please find enclosed the output of ./configure. I don’t see anything > apparently wrong. > > I’d be happy to contribute supporting XC on OS X, although I don’t have > much familiarity with the code. Should I subscribe to some developer > mailing list? > > Nicola > > > > > On 31/ott/2013, at 03:08, Koichi Suzuki <koi...@gm...> wrote: > > I'm interested if ./configure is successful. > > Maybe the patch Michael suggested may not be sufficient. I suspect > there's another problem in ./configure. If you allow me some time (maybe > some time next week) until I upgrade my Macs to Marberics, I can reproduce > the problem. > > Please understand that XC has not announced OS X support so far because we > don't have sufficient resource. It will be nice if you help to support XC > on OS X, or any other platforms other than Intel Linux. > > Regards; > > --- > Koichi Suzuki > > > 2013/10/30 DIMI <nic...@un...> > >> Thanks, the patch can now be applied. But, it doesn’t fix the problem: I >> still get the same build errors. >> >> Nicola >> >> On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: >> >> Because the patch is for vanilla PG. Sometimes we have patch conflict. >> Here's a hack of the patch. Because the nature of the patch does not >> have any bad influence, I hope you can try this. Please let me know how >> it works. >> >> # Please understand that this is really a quick hack and I'm not tracking >> this patch in a good manner. >> >> Good Luck; >> >> --- >> Koichi Suzuki >> >> >> 2013/10/30 DIMI <nic...@un...> >> >>> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> >>> wrote: >>> >>> > There have been fixes these days in Postgres core for Mavericks for >>> strlcpy: >>> > >>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >>> >>> I cannot apply that patch to Postgres-XC 1.1. And after making the >>> change manually, I still get the same build errors. Am I missing something? >>> >>> Nicola >>> >>> >> <tupdesc.c.patch> >> >> >> > > > |
|
From: DIMI <nic...@un...> - 2013-10-31 06:13:50
|
Please find enclosed the output of ./configure. I don’t see anything apparently wrong. I’d be happy to contribute supporting XC on OS X, although I don’t have much familiarity with the code. Should I subscribe to some developer mailing list? Nicola On 31/ott/2013, at 03:08, Koichi Suzuki <koi...@gm...> wrote: > I'm interested if ./configure is successful. > > Maybe the patch Michael suggested may not be sufficient. I suspect there's another problem in ./configure. If you allow me some time (maybe some time next week) until I upgrade my Macs to Marberics, I can reproduce the problem. > > Please understand that XC has not announced OS X support so far because we don't have sufficient resource. It will be nice if you help to support XC on OS X, or any other platforms other than Intel Linux. > > Regards; > > --- > Koichi Suzuki > > > 2013/10/30 DIMI <nic...@un...> > Thanks, the patch can now be applied. But, it doesn’t fix the problem: I still get the same build errors. > > Nicola > > On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: > >> Because the patch is for vanilla PG. Sometimes we have patch conflict. Here's a hack of the patch. Because the nature of the patch does not have any bad influence, I hope you can try this. Please let me know how it works. >> >> # Please understand that this is really a quick hack and I'm not tracking this patch in a good manner. >> >> Good Luck; >> >> --- >> Koichi Suzuki >> >> >> 2013/10/30 DIMI <nic...@un...> >> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> wrote: >> >> > There have been fixes these days in Postgres core for Mavericks for strlcpy: >> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >> >> I cannot apply that patch to Postgres-XC 1.1. And after making the change manually, I still get the same build errors. Am I missing something? >> >> Nicola >> >> >> <tupdesc.c.patch> > > |
|
From: Koichi S. <koi...@gm...> - 2013-10-31 02:08:34
|
I'm interested if ./configure is successful. Maybe the patch Michael suggested may not be sufficient. I suspect there's another problem in ./configure. If you allow me some time (maybe some time next week) until I upgrade my Macs to Marberics, I can reproduce the problem. Please understand that XC has not announced OS X support so far because we don't have sufficient resource. It will be nice if you help to support XC on OS X, or any other platforms other than Intel Linux. Regards; --- Koichi Suzuki 2013/10/30 DIMI <nic...@un...> > Thanks, the patch can now be applied. But, it doesn’t fix the problem: I > still get the same build errors. > > Nicola > > On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: > > Because the patch is for vanilla PG. Sometimes we have patch conflict. > Here's a hack of the patch. Because the nature of the patch does not have > any bad influence, I hope you can try this. Please let me know how it > works. > > # Please understand that this is really a quick hack and I'm not tracking > this patch in a good manner. > > Good Luck; > > --- > Koichi Suzuki > > > 2013/10/30 DIMI <nic...@un...> > >> On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> >> wrote: >> >> > There have been fixes these days in Postgres core for Mavericks for >> strlcpy: >> > >> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì >> >> I cannot apply that patch to Postgres-XC 1.1. And after making the change >> manually, I still get the same build errors. Am I missing something? >> >> Nicola >> >> > <tupdesc.c.patch> > > > |
|
From: DIMI <nic...@un...> - 2013-10-30 09:14:16
|
Thanks, the patch can now be applied. But, it doesn’t fix the problem: I still get the same build errors. Nicola On 30/ott/2013, at 09:58, Koichi Suzuki <koi...@gm...> wrote: > Because the patch is for vanilla PG. Sometimes we have patch conflict. Here's a hack of the patch. Because the nature of the patch does not have any bad influence, I hope you can try this. Please let me know how it works. > > # Please understand that this is really a quick hack and I'm not tracking this patch in a good manner. > > Good Luck; > > --- > Koichi Suzuki > > > 2013/10/30 DIMI <nic...@un...> > On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> wrote: > > > There have been fixes these days in Postgres core for Mavericks for strlcpy: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì > > I cannot apply that patch to Postgres-XC 1.1. And after making the change manually, I still get the same build errors. Am I missing something? > > Nicola > > > <tupdesc.c.patch> |
|
From: Michael P. <mic...@gm...> - 2013-10-30 08:51:14
|
On Wed, Oct 30, 2013 at 8:39 AM, Koichi Suzuki <koi...@gm...> wrote: > I don't understand quite well about this. Nicola successfully built > PG9.3.1 with Marvericks, while you mentioned that the code is not 9.3.1 but > in the latest part of REL9_3_STABLE, which is not available with PG 9.3.1. > > Could you give me some more clarification on this? Oops, sorry. You are right. 9.3.1 compiles well with clang on Mavericks. So if REL1_2_STABLE of XC is merged up to 9.3.1 or even the latest commit of Postgres' REL9_3_STABLE it might be fine. For master though... I am not sure. There might be as well some issues related to XC code itself. -- Michael |
|
From: Koichi S. <koi...@gm...> - 2013-10-30 08:39:57
|
I don't understand quite well about this. Nicola successfully built PG9.3.1 with Marvericks, while you mentioned that the code is not 9.3.1 but in the latest part of REL9_3_STABLE, which is not available with PG 9.3.1. Could you give me some more clarification on this? Regards; --- Koichi Suzuki 2013/10/30 Michael Paquier <mic...@gm...> > On Wed, Oct 30, 2013 at 7:04 AM, Koichi Suzuki <koi...@gm...> > wrote: > > I see. We're merging PostgreSQL9.3.1 code into XC. Hope this helps > > building XC with Marverics. Merge with PostgreSQL 9.3 will be > available > > as XC release 1.2, hopefully at the end of the year. > There have been fixes these days in Postgres core for Mavericks for > strlcpy: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758 > Note that merging 9.3.1 into REL1_2_STABLE will *not* remove the issue > as it has been committed after the release of 9.3.1. In the case of > the merge of master branch of Postgres with XC master also this will > not be included by default, as this should be done based on commit of > `git merge-base master REL9_3_STABLE` and the fix on Postgres core has > been added afterwards AFAIK. > -- > Michael > |
|
From: Michael P. <mic...@gm...> - 2013-10-30 08:34:58
|
On Wed, Oct 30, 2013 at 8:05 AM, Koichi Suzuki <koi...@gm...> wrote: > Maybe we should merge with PG REL9_3_STABLE's latest status as possible, No. The merge to 9.3 should be done up to the merge base of Postgres' master and REL9_3_STABLE. > or cherry-pick this specific commit. This would be better. -- Michael |
|
From: DIMI <nic...@un...> - 2013-10-30 08:17:32
|
On 30/ott/2013, at 08:51, Michael Paquier <mic...@gm...> wrote: > There have been fixes these days in Postgres core for Mavericks for strlcpy: > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758ì I cannot apply that patch to Postgres-XC 1.1. And after making the change manually, I still get the same build errors. Am I missing something? Nicola |
|
From: Koichi S. <koi...@gm...> - 2013-10-30 08:05:46
|
MIchael; Thanks for the info. Maybe we should merge with PG REL9_3_STABLE's latest status as possible, or cherry-pick this specific commit. Regards; --- Koichi Suzuki 2013/10/30 Michael Paquier <mic...@gm...> > On Wed, Oct 30, 2013 at 7:04 AM, Koichi Suzuki <koi...@gm...> > wrote: > > I see. We're merging PostgreSQL9.3.1 code into XC. Hope this helps > > building XC with Marverics. Merge with PostgreSQL 9.3 will be > available > > as XC release 1.2, hopefully at the end of the year. > There have been fixes these days in Postgres core for Mavericks for > strlcpy: > > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758 > Note that merging 9.3.1 into REL1_2_STABLE will *not* remove the issue > as it has been committed after the release of 9.3.1. In the case of > the merge of master branch of Postgres with XC master also this will > not be included by default, as this should be done based on commit of > `git merge-base master REL9_3_STABLE` and the fix on Postgres core has > been added afterwards AFAIK. > -- > Michael > |
|
From: Michael P. <mic...@gm...> - 2013-10-30 07:51:20
|
On Wed, Oct 30, 2013 at 7:04 AM, Koichi Suzuki <koi...@gm...> wrote: > I see. We're merging PostgreSQL9.3.1 code into XC. Hope this helps > building XC with Marverics. Merge with PostgreSQL 9.3 will be available > as XC release 1.2, hopefully at the end of the year. There have been fixes these days in Postgres core for Mavericks for strlcpy: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a1f86e70c8d9a152eaa50cc17e5249da10d3e758 Note that merging 9.3.1 into REL1_2_STABLE will *not* remove the issue as it has been committed after the release of 9.3.1. In the case of the merge of master branch of Postgres with XC master also this will not be included by default, as this should be done based on commit of `git merge-base master REL9_3_STABLE` and the fix on Postgres core has been added afterwards AFAIK. -- Michael |
|
From: Koichi S. <koi...@gm...> - 2013-10-30 07:04:52
|
I see. We're merging PostgreSQL9.3.1 code into XC. Hope this helps
building XC with Marverics. Merge with PostgreSQL 9.3 will be available
as XC release 1.2, hopefully at the end of the year.
Regards;
---
Koichi Suzuki
2013/10/30 DIMI <nic...@un...>
> PostgreSQL 9.3.1 builds just fine. I, too, believe that it is
> Maverick-specific, since I had no problems with building Postgres-XC on
> previous systems.
>
> Nicola
>
> On 30/ott/2013, at 02:45, Koichi Suzuki <koi...@gm...> wrote:
>
> I tried ./configure at Mountain Lion without any problems. Build was
> successful too. Maybe this is Marverick-specific.
>
> Postgres-XC imports most of ./configure from PostgreSQL. Could you try
> ./configure for PostgreSQL and see if you have similar problems? If you
> are successful, maybe we can update our ./configure based on the latest PG
> resource. Sorry I cannot find a time to upgrade my Macs into Marvericks
> for this couple of days at least.
>
> Best regards;
>
> ---
> Koichi Suzuki
>
>
> 2013/10/29 DIMI <nic...@un...>
>
>> Name: Nicola Vitacolonna
>> Email: nvi...@gm...
>>
>> System Configuration:
>> ---------------------
>> Architecture : Intel Pentium
>> Operating System : OS X 10.9 (Mavericks)
>> Postgres-XC version : Postgres-XC 1.1
>> Compiler used : gcc —version
>>
>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
>> Target: x86_64-apple-darwin13.0.0
>> Thread model: posix
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
>> --with-gxx-include-dir=/usr/include/c++/4.2.1
>>
>>
>> Please enter a FULL description of your problem:
>> ------------------------------------------------
>> ./configure & make fails with the following errors, possibly related
>> with the fact that clang links against libc++ instead of libstdc++:
>>
>> […]
>> cc -DPGXC -O2 -Wall -Wmissing-prototypes -Wpointer-arith
>> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
>> -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include -c
>> -o strlcpy.o strlcpy.c
>> strlcpy.c:46:1: error: expected parameter declarator
>> strlcpy(char *dst, const char *src, size_t siz)
>> ^
>> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> /usr/include/secure/_common.h:39:62: note: expanded from macro
>> '__darwin_obsz'
>> #define __darwin_obsz(object) __builtin_object_size (object,
>> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
>> ^
>> /usr/include/secure/_common.h:30:32: note: expanded from macro
>> '_USE_FORTIFY_LEVEL'
>> # define _USE_FORTIFY_LEVEL 2
>> ^
>> strlcpy.c:46:1: error: expected ')'
>> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> /usr/include/secure/_common.h:39:62: note: expanded from macro
>> '__darwin_obsz'
>> #define __darwin_obsz(object) __builtin_object_size (object,
>> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
>> ^
>> /usr/include/secure/_common.h:30:32: note: expanded from macro
>> '_USE_FORTIFY_LEVEL'
>> # define _USE_FORTIFY_LEVEL 2
>> ^
>> strlcpy.c:46:1: note: to match this '('
>> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> /usr/include/secure/_common.h:39:53: note: expanded from macro
>> '__darwin_obsz'
>> #define __darwin_obsz(object) __builtin_object_size (object,
>> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
>> ^
>> strlcpy.c:46:1: warning: type specifier missing, defaults to 'int'
>> [-Wimplicit-int]
>> strlcpy(char *dst, const char *src, size_t siz)
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^~~~~~~~~~~~~~~~~~~~
>> /usr/include/secure/_common.h:39:31: note: expanded from macro
>> '__darwin_obsz'
>> #define __darwin_obsz(object) __builtin_object_size (object,
>> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
>> ^~~~~~~~~~~~~~~~~~~~~
>> strlcpy.c:46:1: error: conflicting types for '__builtin___strlcpy_chk'
>> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> strlcpy.c:46:1: note: '__builtin___strlcpy_chk' is a builtin with type
>> 'unsigned long (char *, const char *, unsigned long, unsigned long)'
>> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> strlcpy.c:46:1: error: definition of builtin function
>> '__builtin___strlcpy_chk'
>> strlcpy(char *dst, const char *src, size_t siz)
>> ^
>> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
>> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
>> ^
>> 1 warning and 4 errors generated.
>> make[3]: *** [strlcpy.o] Error 1
>> make[2]: *** [all-libpq-recurse] Error 2
>> make[1]: *** [all-gtm-recurse] Error 2
>> make: *** [all-src-recurse] Error 2
>>
>>
>> Please describe a way to repeat the problem. Please try to provide a
>> concise reproducible example, if at all possible:
>> ----------------------------------------------------------------------
>> Just ./configure & make.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android is increasing in popularity, but the open development platform
>> that
>> developers love is also attractive to malware creators. Download this
>> white
>> paper to learn more about secure code signing practices that can help keep
>> Android apps secure.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-bugs mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
>>
>
>
>
|
|
From: DIMI <nic...@un...> - 2013-10-30 06:31:50
|
PostgreSQL 9.3.1 builds just fine. I, too, believe that it is Maverick-specific, since I had no problems with building Postgres-XC on previous systems.
Nicola
On 30/ott/2013, at 02:45, Koichi Suzuki <koi...@gm...> wrote:
> I tried ./configure at Mountain Lion without any problems. Build was successful too. Maybe this is Marverick-specific.
>
> Postgres-XC imports most of ./configure from PostgreSQL. Could you try ./configure for PostgreSQL and see if you have similar problems? If you are successful, maybe we can update our ./configure based on the latest PG resource. Sorry I cannot find a time to upgrade my Macs into Marvericks for this couple of days at least.
>
> Best regards;
>
> ---
> Koichi Suzuki
>
>
> 2013/10/29 DIMI <nic...@un...>
> Name: Nicola Vitacolonna
> Email: nvi...@gm...
>
> System Configuration:
> ---------------------
> Architecture : Intel Pentium
> Operating System : OS X 10.9 (Mavericks)
> Postgres-XC version : Postgres-XC 1.1
> Compiler used : gcc —version
>
> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
> Target: x86_64-apple-darwin13.0.0
> Thread model: posix
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
>
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
> ./configure & make fails with the following errors, possibly related with the fact that clang links against libc++ instead of libstdc++:
>
> […]
> cc -DPGXC -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include -c -o strlcpy.o strlcpy.c
> strlcpy.c:46:1: error: expected parameter declarator
> strlcpy(char *dst, const char *src, size_t siz)
> ^
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> /usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'
> # define _USE_FORTIFY_LEVEL 2
> ^
> strlcpy.c:46:1: error: expected ')'
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> /usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'
> # define _USE_FORTIFY_LEVEL 2
> ^
> strlcpy.c:46:1: note: to match this '('
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> strlcpy.c:46:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> strlcpy(char *dst, const char *src, size_t siz)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^~~~~~~~~~~~~~~~~~~~
> /usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^~~~~~~~~~~~~~~~~~~~~
> strlcpy.c:46:1: error: conflicting types for '__builtin___strlcpy_chk'
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> strlcpy.c:46:1: note: '__builtin___strlcpy_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> strlcpy.c:46:1: error: definition of builtin function '__builtin___strlcpy_chk'
> strlcpy(char *dst, const char *src, size_t siz)
> ^
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> 1 warning and 4 errors generated.
> make[3]: *** [strlcpy.o] Error 1
> make[2]: *** [all-libpq-recurse] Error 2
> make[1]: *** [all-gtm-recurse] Error 2
> make: *** [all-src-recurse] Error 2
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
> Just ./configure & make.
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-bugs mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
>
|
|
From: Koichi S. <koi...@gm...> - 2013-10-30 01:45:10
|
I tried ./configure at Mountain Lion without any problems. Build was
successful too. Maybe this is Marverick-specific.
Postgres-XC imports most of ./configure from PostgreSQL. Could you try
./configure for PostgreSQL and see if you have similar problems? If you
are successful, maybe we can update our ./configure based on the latest PG
resource. Sorry I cannot find a time to upgrade my Macs into Marvericks
for this couple of days at least.
Best regards;
---
Koichi Suzuki
2013/10/29 DIMI <nic...@un...>
> Name: Nicola Vitacolonna
> Email: nvi...@gm...
>
> System Configuration:
> ---------------------
> Architecture : Intel Pentium
> Operating System : OS X 10.9 (Mavericks)
> Postgres-XC version : Postgres-XC 1.1
> Compiler used : gcc —version
>
> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
> Target: x86_64-apple-darwin13.0.0
> Thread model: posix
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
>
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
> ./configure & make fails with the following errors, possibly related with
> the fact that clang links against libc++ instead of libstdc++:
>
> […]
> cc -DPGXC -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include -c
> -o strlcpy.o strlcpy.c
> strlcpy.c:46:1: error: expected parameter declarator
> strlcpy(char *dst, const char *src, size_t siz)
> ^
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:62: note: expanded from macro
> '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object,
> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> /usr/include/secure/_common.h:30:32: note: expanded from macro
> '_USE_FORTIFY_LEVEL'
> # define _USE_FORTIFY_LEVEL 2
> ^
> strlcpy.c:46:1: error: expected ')'
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:62: note: expanded from macro
> '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object,
> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> /usr/include/secure/_common.h:30:32: note: expanded from macro
> '_USE_FORTIFY_LEVEL'
> # define _USE_FORTIFY_LEVEL 2
> ^
> strlcpy.c:46:1: note: to match this '('
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> /usr/include/secure/_common.h:39:53: note: expanded from macro
> '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object,
> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^
> strlcpy.c:46:1: warning: type specifier missing, defaults to 'int'
> [-Wimplicit-int]
> strlcpy(char *dst, const char *src, size_t siz)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^~~~~~~~~~~~~~~~~~~~
> /usr/include/secure/_common.h:39:31: note: expanded from macro
> '__darwin_obsz'
> #define __darwin_obsz(object) __builtin_object_size (object,
> _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
> ^~~~~~~~~~~~~~~~~~~~~
> strlcpy.c:46:1: error: conflicting types for '__builtin___strlcpy_chk'
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> strlcpy.c:46:1: note: '__builtin___strlcpy_chk' is a builtin with type
> 'unsigned long (char *, const char *, unsigned long, unsigned long)'
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> strlcpy.c:46:1: error: definition of builtin function
> '__builtin___strlcpy_chk'
> strlcpy(char *dst, const char *src, size_t siz)
> ^
> /usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
> __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
> ^
> 1 warning and 4 errors generated.
> make[3]: *** [strlcpy.o] Error 1
> make[2]: *** [all-libpq-recurse] Error 2
> make[1]: *** [all-gtm-recurse] Error 2
> make: *** [all-src-recurse] Error 2
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
> Just ./configure & make.
>
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-bugs mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
>
|
|
From: DIMI <nic...@un...> - 2013-10-29 13:35:29
|
Name: Nicola Vitacolonna
Email: nvi...@gm...
System Configuration:
---------------------
Architecture : Intel Pentium
Operating System : OS X 10.9 (Mavericks)
Postgres-XC version : Postgres-XC 1.1
Compiler used : gcc —version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Please enter a FULL description of your problem:
------------------------------------------------
./configure & make fails with the following errors, possibly related with the fact that clang links against libc++ instead of libstdc++:
[…]
cc -DPGXC -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -I../../../src/include -c -o strlcpy.o strlcpy.c
strlcpy.c:46:1: error: expected parameter declarator
strlcpy(char *dst, const char *src, size_t siz)
^
/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'
# define _USE_FORTIFY_LEVEL 2
^
strlcpy.c:46:1: error: expected ')'
/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'
# define _USE_FORTIFY_LEVEL 2
^
strlcpy.c:46:1: note: to match this '('
/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^
strlcpy.c:46:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
strlcpy(char *dst, const char *src, size_t siz)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^~~~~~~~~~~~~~~~~~~~
/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
^~~~~~~~~~~~~~~~~~~~~
strlcpy.c:46:1: error: conflicting types for '__builtin___strlcpy_chk'
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
strlcpy.c:46:1: note: '__builtin___strlcpy_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
strlcpy.c:46:1: error: definition of builtin function '__builtin___strlcpy_chk'
strlcpy(char *dst, const char *src, size_t siz)
^
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
__builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))
^
1 warning and 4 errors generated.
make[3]: *** [strlcpy.o] Error 1
make[2]: *** [all-libpq-recurse] Error 2
make[1]: *** [all-gtm-recurse] Error 2
make: *** [all-src-recurse] Error 2
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
Just ./configure & make.
|
|
From: Julian <jul...@gm...> - 2013-10-08 09:03:59
|
Hi,
When i try to add new coordinator to my cluster but failed, and generate a segmentation fault.
then i try to using gdb to trace it and here is the result.
(gdb) p
$38 = 0x2ac8650 "SET default_with_oids = false;"
(gdb) c
Continuing.
Breakpoint 2, PostgresMain (argc=1, argv=0x2ab14f8, dbname=0x2ab13a8 "pgxc", username=0x2ab1390 "pgxc") at postgres.c:4198
4198 SetCurrentStatementStartTimestamp();
(gdb) p
$39 = 0x2ac8650 "CREATE TABLE user_info_hash (\n id integer NOT NULL,\n firstname text,\n lastname text,\n info text\n)\nDISTRIBUTE BY HASH (id)\nTO NODE (datanode1,datanode2,datanode3);"
(gdb) n
4200 query_string = pq_getmsgstring(&input_message);
(gdb)
4201 pq_getmsgend(&input_message);
(gdb)
4203 exec_simple_query(query_string);
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0x000000000087fa40 in AllocSetAlloc (context=0x2bc5d48, size=280) at aset.c:639
639 set->freelist[fidx] = (AllocChunk) chunk->aset;
(gdb) bt
#0 0x000000000087fa40 in AllocSetAlloc (context=0x2bc5d48, size=280) at aset.c:639
#1 0x00000000008808fa in MemoryContextAlloc (context=0x2bc5d48, size=280) at mcxt.c:580
#2 0x0000000000472344 in CreateTemplateTupleDesc (natts=2, hasoid=0 '\000') at tupdesc.c:65
#3 0x0000000000505243 in ConstructTupleDescriptor (heapRelation=0x7ffcaa266690, indexInfo=0x2bded68, indexColNames=0x2bdbb48, accessMethodObjectId=403,
collationObjectId=0x7fff49a3d9a0, classObjectId=0x7fff49a3d990) at index.c:298
#4 0x0000000000506069 in index_create (heapRelation=0x7ffcaa266690, indexRelationName=0x7fff49a3d9b0 "pg_toast_24590_index", indexRelationId=0, relFileNode=0,
indexInfo=0x2bded68, indexColNames=0x2bdbb48, accessMethodObjectId=403, tableSpaceId=0, collationObjectId=0x7fff49a3d9a0, classObjectId=0x7fff49a3d990,
coloptions=0x7fff49a3d980, reloptions=0, isprimary=1 '\001', isconstraint=0 '\000', deferrable=0 '\000', initdeferred=0 '\000', allow_system_table_mods=1 '\001',
skip_build=0 '\000', concurrent=0 '\000') at index.c:777
#5 0x000000000052afbc in create_toast_table (rel=0x7ffcaa1c8bf8, toastOid=0, toastIndexOid=0, reloptions=0) at toasting.c:277
#6 0x000000000052a993 in AlterTableCreateToastTable (relOid=24590, reloptions=0) at toasting.c:70
#7 0x00000000007549fd in standard_ProcessUtility (parsetree=0x2ac9b70,
queryString=0x2ac8650 "CREATE TABLE user_info_hash (\n id integer NOT NULL,\n firstname text,\n lastname text,\n info text\n)\nDISTRIBUTE BY HASH (id)\nTO NODE (datanode1,datanode2,datanode3);", params=0x0, isTopLevel=1 '\001', dest=0x2ac9f10, sentToRemote=0 '\000', completionTag=0x7fff49a3e110 "") at utility.c:746
#8 0x0000000000754064 in ProcessUtility (parsetree=0x2ac9b70,
queryString=0x2ac8650 "CREATE TABLE user_info_hash (\n id integer NOT NULL,\n firstname text,\n lastname text,\n info text\n)\nDISTRIBUTE BY HASH (id)\nTO NODE (datanode1,datanode2,datanode3);", params=0x0, isTopLevel=1 '\001', dest=0x2ac9f10, sentToRemote=0 '\000', completionTag=0x7fff49a3e110 "") at utility.c:377
#9 0x0000000000752ff1 in PortalRunUtility (portal=0x2bc8e50, utilityStmt=0x2ac9b70, isTopLevel=1 '\001', dest=0x2ac9f10, completionTag=0x7fff49a3e110 "")
at pquery.c:1283
#10 0x000000000075321e in PortalRunMulti (portal=0x2bc8e50, isTopLevel=1 '\001', dest=0x2ac9f10, altdest=0x2ac9f10, completionTag=0x7fff49a3e110 "") at pquery.c:1430
#11 0x00000000007526c5 in PortalRun (portal=0x2bc8e50, count=9223372036854775807, isTopLevel=1 '\001', dest=0x2ac9f10, altdest=0x2ac9f10,
completionTag=0x7fff49a3e110 "") at pquery.c:880
#12 0x000000000074c244 in exec_simple_query (
query_string=0x2ac8650 "CREATE TABLE user_info_hash (\n id integer NOT NULL,\n firstname text,\n lastname text,\n info text\n)\nDISTRIBUTE BY HASH (id)\nTO NODE (datanode1,datanode2,datanode3);") at postgres.c:1136
#13 0x0000000000750644 in PostgresMain (argc=1, argv=0x2ab14f8, dbname=0x2ab13a8 "pgxc", username=0x2ab1390 "pgxc") at postgres.c:4203
#14 0x00000000006fa60f in BackendRun (port=0x2ad2d80) at postmaster.c:3804
#15 0x00000000006f9d14 in BackendStartup (port=0x2ad2d80) at postmaster.c:3494
#16 0x00000000006f6ace in ServerLoop () at postmaster.c:1472
#17 0x00000000006f64d7 in PostmasterMain (argc=6, argv=0x2aaf2a0) at postmaster.c:1232
#18 0x000000000065f56a in main (argc=6, argv=0x2aaf2a0) at main.c:199
and caused by this sql statement
CREATE TABLE user_info_hash (
id integer NOT NULL,
firstname text,
lastname text,
info text
)
DISTRIBUTE BY HASH (id)
TO NODE (datanode1,datanode2,datanode3);
Regards;
--
Julian
使用 Sparrow (http://www.sparrowmailapp.com/?sig) 發信
|
|
From: Koichi S. <koi...@gm...> - 2013-09-25 05:11:24
|
Yes, I understand it is a bug. I suppose the fix is a part of Trigger support. Could be back-ported to 1.0.x but it may not be simple. Regards; --- Koichi Suzuki 2013/9/25 Nikhil Sontakke <ni...@st...> > This indeed is the issue. The schema name is not being used properly. > > Any specific reason you are suing REL 10? > > Can you not switch to REL 11? I checked and it seems to be fixed in REL 11. > > Regards, > Nikhils > > > > On Wed, Sep 25, 2013 at 6:37 AM, Nikhil Sontakke <ni...@st...>wrote: > >> Hi William, >> >> >>> \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >>> >>> ERROR: relation "mutect" does not exist >>> >>> >> Hmm, I guess it might be a bug in the COPY code where it's not adding on >> the schema name on the datanode side or something. >> >> Can you please create this mutect table in the default public schema and >> report back if the COPY command still fails? >> >> \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >> >> >> HTH, >> Nikhils >> >> >>> I am not a C programmer so I am at a loss here. I am guessing that >>> COPY.h queries some table other than tables, pg_class or pgxc_class to get >>> the relation information it needs to proceed and that is where the >>> exception is being thrown. Does anyone on the team have any familiarity >>> with this code so they could send me the table name? >>> >>> Absent that, are there any other bulk loading utilities for >>> Postgres-xc (even 3rd party apps) that might work for mr or should I revert >>> to an earlier and possibly more stable version? >>> >>> Thanks again, >>> >>> Bill West >>> >>> >>> >>> From: <West>, William West <ww...@uc...> >>> Date: Monday, September 23, 2013 10:03 AM >>> To: Koichi Suzuki <koi...@gm...> >>> >>> Cc: "pos...@li..." < >>> pos...@li...> >>> Subject: Re: [Postgres-xc-bugs] Copy Command >>> >>> Thanks Koichi, >>> >>> I checked pgxc_class on both nodes. The table appears in the node I >>> created it as seen highlighted in this query result: >>> >>> postgres=# select * from pgxc_class; >>> pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | >>> nodeoids >>> >>> ---------+---------------+----------+-----------------+---------------+------------- >>> 16387 | R | 0 | 0 | 0 | >>> 16384 >>> 16396 | H | 1 | 1 | 4096 | >>> 16384 >>> 16495 | H | 1 | 1 | 4096 | >>> 16384 16385 >>> 16501 | H | 1 | 1 | 4096 | >>> 16384 16385 >>> 16544 | H | 1 | 1 | 4096 | >>> 16384 16385 >>> 24688 | R | 0 | 0 | 0 | >>> 16384 16385 >>> (6 rows) >>> >>> When I look at my other node and run the same query I get: >>> >>> postgres=# select * from pgxc_class; >>> pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | >>> nodeoids >>> >>> ---------+---------------+----------+-----------------+---------------+------------- >>> 16386 | H | 1 | 1 | 4096 | >>> 16384 >>> 24603 | H | 1 | 1 | 4096 | >>> 16385 16384 >>> 24609 | H | 1 | 1 | 4096 | >>> 16385 16384 >>> 24652 | H | 1 | 1 | 4096 | >>> 16385 16384 >>> 32820 | R | 0 | 0 | 0 | >>> 16385 16384 >>> >>> I believe the highlighted table above is the same table. I can query >>> it on either node however I notice that the pcrelid is different on each >>> node. Is this significant? >>> >>> Regards, >>> >>> Bill West >>> >>> >>> >>> >>> From: Koichi Suzuki <koi...@gm...> >>> Date: Sunday, September 22, 2013 6:17 PM >>> To: William West <ww...@uc...> >>> Cc: "pos...@li..." < >>> pos...@li...> >>> Subject: Re: [Postgres-xc-bugs] Copy Command >>> >>> Sorry for the late response. >>> >>> Could you check pgxc_class catalog to see if the table is registered >>> to this catalog as well? Usually, if you've created the table with >>> conventional CREATE TABLE command from one of the coordinators, the >>> definition should have propagated to all the coordinators. >>> >>> We're using COPY command in DBT-2 and does not have any significant >>> problems. >>> >>> --- >>> Koichi Suzuki >>> >>> >>> 2013/9/19 West, William <ww...@uc...> >>> >>>> All, >>>> >>>> I am attempting to use the copy command (as I previously did >>>> successfully in Postgres) to copy data from a file on the file system. When >>>> I try to upload data to the XC instance I get a 'relation does not exist' >>>> error. However if I check the metadata table, called tables, it is in there: >>>> >>>> postgres=# select * from information_schema.tables where table_type = >>>> 'BASE TABLE'; >>>> table_catalog | table_schema | table_name | >>>> table_type | self_referencing_column_name | reference_generation | >>>> user_defined_type_catalog | >>>> user_defined_type_schema | user_defined_type_name | is_insertable_into >>>> | is_typed | commit_action >>>> >>>> ---------------+--------------------+-------------------------+------------+------------------------------+----------------------+---------------------------+ >>>> >>>> --------------------------+------------------------+--------------------+----------+--------------- >>>> postgres | staging | mutect | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | staging | vcf | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_features | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | gene | vcf | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | staging | source_downloads | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_cast | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_am | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_attrdef | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | public | products2 | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_sizing_profiles | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_sizing | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_parts | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_packages | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_languages | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | information_schema | sql_implementation_info | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | public | products | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_collation | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_seclabel | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_default_acl | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_foreign_table | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pgxc_group | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pgxc_node | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pgxc_class | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_foreign_server | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_foreign_data_wrapper | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_extension | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres | pg_catalog | pg_ts_template | BASE >>>> TABLE | | | >>>> | >>>> | | YES >>>> | NO | >>>> postgres=# \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >>>> ERROR: relation "mutect" does not exist >>>> >>>> Is this a known bug (version 1.0.3) or is there a different command >>>> for Copy in XC? If it is a bug is there any work around for bulk loading >>>> data? >>>> >>>> Thanks, >>>> >>>> Bill West >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, >>>> SharePoint >>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >>>> includes >>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Postgres-xc-bugs mailing list >>>> Pos...@li... >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>> >>> _______________________________________________ >>> Postgres-xc-bugs mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >>> >>> >> >> >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > |
|
From: Nikhil S. <ni...@st...> - 2013-09-25 01:17:58
|
This indeed is the issue. The schema name is not being used properly. Any specific reason you are suing REL 10? Can you not switch to REL 11? I checked and it seems to be fixed in REL 11. Regards, Nikhils On Wed, Sep 25, 2013 at 6:37 AM, Nikhil Sontakke <ni...@st...>wrote: > Hi William, > > >> \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >> >> ERROR: relation "mutect" does not exist >> >> > Hmm, I guess it might be a bug in the COPY code where it's not adding on > the schema name on the datanode side or something. > > Can you please create this mutect table in the default public schema and > report back if the COPY command still fails? > > \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; > > > HTH, > Nikhils > > >> I am not a C programmer so I am at a loss here. I am guessing that >> COPY.h queries some table other than tables, pg_class or pgxc_class to get >> the relation information it needs to proceed and that is where the >> exception is being thrown. Does anyone on the team have any familiarity >> with this code so they could send me the table name? >> >> Absent that, are there any other bulk loading utilities for Postgres-xc >> (even 3rd party apps) that might work for mr or should I revert to an >> earlier and possibly more stable version? >> >> Thanks again, >> >> Bill West >> >> >> >> From: <West>, William West <ww...@uc...> >> Date: Monday, September 23, 2013 10:03 AM >> To: Koichi Suzuki <koi...@gm...> >> >> Cc: "pos...@li..." < >> pos...@li...> >> Subject: Re: [Postgres-xc-bugs] Copy Command >> >> Thanks Koichi, >> >> I checked pgxc_class on both nodes. The table appears in the node I >> created it as seen highlighted in this query result: >> >> postgres=# select * from pgxc_class; >> pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | >> nodeoids >> >> ---------+---------------+----------+-----------------+---------------+------------- >> 16387 | R | 0 | 0 | 0 | >> 16384 >> 16396 | H | 1 | 1 | 4096 | >> 16384 >> 16495 | H | 1 | 1 | 4096 | >> 16384 16385 >> 16501 | H | 1 | 1 | 4096 | >> 16384 16385 >> 16544 | H | 1 | 1 | 4096 | >> 16384 16385 >> 24688 | R | 0 | 0 | 0 | >> 16384 16385 >> (6 rows) >> >> When I look at my other node and run the same query I get: >> >> postgres=# select * from pgxc_class; >> pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | >> nodeoids >> >> ---------+---------------+----------+-----------------+---------------+------------- >> 16386 | H | 1 | 1 | 4096 | >> 16384 >> 24603 | H | 1 | 1 | 4096 | >> 16385 16384 >> 24609 | H | 1 | 1 | 4096 | >> 16385 16384 >> 24652 | H | 1 | 1 | 4096 | >> 16385 16384 >> 32820 | R | 0 | 0 | 0 | >> 16385 16384 >> >> I believe the highlighted table above is the same table. I can query it >> on either node however I notice that the pcrelid is different on each node. >> Is this significant? >> >> Regards, >> >> Bill West >> >> >> >> >> From: Koichi Suzuki <koi...@gm...> >> Date: Sunday, September 22, 2013 6:17 PM >> To: William West <ww...@uc...> >> Cc: "pos...@li..." < >> pos...@li...> >> Subject: Re: [Postgres-xc-bugs] Copy Command >> >> Sorry for the late response. >> >> Could you check pgxc_class catalog to see if the table is registered to >> this catalog as well? Usually, if you've created the table with >> conventional CREATE TABLE command from one of the coordinators, the >> definition should have propagated to all the coordinators. >> >> We're using COPY command in DBT-2 and does not have any significant >> problems. >> >> --- >> Koichi Suzuki >> >> >> 2013/9/19 West, William <ww...@uc...> >> >>> All, >>> >>> I am attempting to use the copy command (as I previously did >>> successfully in Postgres) to copy data from a file on the file system. When >>> I try to upload data to the XC instance I get a 'relation does not exist' >>> error. However if I check the metadata table, called tables, it is in there: >>> >>> postgres=# select * from information_schema.tables where table_type = >>> 'BASE TABLE'; >>> table_catalog | table_schema | table_name | >>> table_type | self_referencing_column_name | reference_generation | >>> user_defined_type_catalog | >>> user_defined_type_schema | user_defined_type_name | is_insertable_into >>> | is_typed | commit_action >>> >>> ---------------+--------------------+-------------------------+------------+------------------------------+----------------------+---------------------------+ >>> >>> --------------------------+------------------------+--------------------+----------+--------------- >>> postgres | staging | mutect | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | staging | vcf | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_features | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | gene | vcf | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | staging | source_downloads | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_cast | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_am | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_attrdef | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | public | products2 | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_sizing_profiles | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_sizing | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_parts | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_packages | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_languages | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | information_schema | sql_implementation_info | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | public | products | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_collation | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_seclabel | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_default_acl | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_foreign_table | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pgxc_group | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pgxc_node | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pgxc_class | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_foreign_server | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_foreign_data_wrapper | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_extension | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres | pg_catalog | pg_ts_template | BASE >>> TABLE | | | >>> | >>> | | YES >>> | NO | >>> postgres=# \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >>> ERROR: relation "mutect" does not exist >>> >>> Is this a known bug (version 1.0.3) or is there a different command >>> for Copy in XC? If it is a bug is there any work around for bulk loading >>> data? >>> >>> Thanks, >>> >>> Bill West >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, >>> SharePoint >>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >>> includes >>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Postgres-xc-bugs mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >>> >>> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >> >> > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: Nikhil S. <ni...@st...> - 2013-09-25 01:07:28
|
Hi William, > \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; > > ERROR: relation "mutect" does not exist > > Hmm, I guess it might be a bug in the COPY code where it's not adding on the schema name on the datanode side or something. Can you please create this mutect table in the default public schema and report back if the COPY command still fails? \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; HTH, Nikhils > I am not a C programmer so I am at a loss here. I am guessing that > COPY.h queries some table other than tables, pg_class or pgxc_class to get > the relation information it needs to proceed and that is where the > exception is being thrown. Does anyone on the team have any familiarity > with this code so they could send me the table name? > > Absent that, are there any other bulk loading utilities for Postgres-xc > (even 3rd party apps) that might work for mr or should I revert to an > earlier and possibly more stable version? > > Thanks again, > > Bill West > > > > From: <West>, William West <ww...@uc...> > Date: Monday, September 23, 2013 10:03 AM > To: Koichi Suzuki <koi...@gm...> > > Cc: "pos...@li..." < > pos...@li...> > Subject: Re: [Postgres-xc-bugs] Copy Command > > Thanks Koichi, > > I checked pgxc_class on both nodes. The table appears in the node I > created it as seen highlighted in this query result: > > postgres=# select * from pgxc_class; > pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | > nodeoids > > ---------+---------------+----------+-----------------+---------------+------------- > 16387 | R | 0 | 0 | 0 | > 16384 > 16396 | H | 1 | 1 | 4096 | > 16384 > 16495 | H | 1 | 1 | 4096 | > 16384 16385 > 16501 | H | 1 | 1 | 4096 | > 16384 16385 > 16544 | H | 1 | 1 | 4096 | > 16384 16385 > 24688 | R | 0 | 0 | 0 | > 16384 16385 > (6 rows) > > When I look at my other node and run the same query I get: > > postgres=# select * from pgxc_class; > pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | > nodeoids > > ---------+---------------+----------+-----------------+---------------+------------- > 16386 | H | 1 | 1 | 4096 | > 16384 > 24603 | H | 1 | 1 | 4096 | > 16385 16384 > 24609 | H | 1 | 1 | 4096 | > 16385 16384 > 24652 | H | 1 | 1 | 4096 | > 16385 16384 > 32820 | R | 0 | 0 | 0 | > 16385 16384 > > I believe the highlighted table above is the same table. I can query it > on either node however I notice that the pcrelid is different on each node. > Is this significant? > > Regards, > > Bill West > > > > > From: Koichi Suzuki <koi...@gm...> > Date: Sunday, September 22, 2013 6:17 PM > To: William West <ww...@uc...> > Cc: "pos...@li..." < > pos...@li...> > Subject: Re: [Postgres-xc-bugs] Copy Command > > Sorry for the late response. > > Could you check pgxc_class catalog to see if the table is registered to > this catalog as well? Usually, if you've created the table with > conventional CREATE TABLE command from one of the coordinators, the > definition should have propagated to all the coordinators. > > We're using COPY command in DBT-2 and does not have any significant > problems. > > --- > Koichi Suzuki > > > 2013/9/19 West, William <ww...@uc...> > >> All, >> >> I am attempting to use the copy command (as I previously did >> successfully in Postgres) to copy data from a file on the file system. When >> I try to upload data to the XC instance I get a 'relation does not exist' >> error. However if I check the metadata table, called tables, it is in there: >> >> postgres=# select * from information_schema.tables where table_type = >> 'BASE TABLE'; >> table_catalog | table_schema | table_name | >> table_type | self_referencing_column_name | reference_generation | >> user_defined_type_catalog | >> user_defined_type_schema | user_defined_type_name | is_insertable_into | >> is_typed | commit_action >> >> ---------------+--------------------+-------------------------+------------+------------------------------+----------------------+---------------------------+ >> >> --------------------------+------------------------+--------------------+----------+--------------- >> postgres | staging | mutect | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | staging | vcf | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_features | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | gene | vcf | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | staging | source_downloads | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_cast | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_am | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_attrdef | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | public | products2 | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_sizing_profiles | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_sizing | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_parts | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_packages | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_languages | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | information_schema | sql_implementation_info | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | public | products | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_collation | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_seclabel | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_default_acl | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_foreign_table | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pgxc_group | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pgxc_node | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pgxc_class | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_foreign_server | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_foreign_data_wrapper | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_extension | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres | pg_catalog | pg_ts_template | BASE >> TABLE | | | >> | >> | | YES | >> NO | >> postgres=# \copy staging.mutect from '/tmp/20.mutect.call_stats.out'; >> ERROR: relation "mutect" does not exist >> >> Is this a known bug (version 1.0.3) or is there a different command for >> Copy in XC? If it is a bug is there any work around for bulk loading data? >> >> Thanks, >> >> Bill West >> >> >> >> ------------------------------------------------------------------------------ >> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, >> SharePoint >> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >> includes >> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Postgres-xc-bugs mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs >> >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Postgres-xc-bugs mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs > > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: West, W. <ww...@uc...> - 2013-09-24 22:38:38
|
All,
OK since copy is working on your end, I assumed that there might have been some corruption on the original install. I also thought I would simplify the configuration by just installing on a single node initially and adding the second node later.
I reinstalled version 1.0.1 on a single node containing 1 GTM, 1 coordinator and 1 datanode. I started it up and added my table called staging.mutect. I then queried tables, pg_class and pgxc_class with the following results:
postgres=# select * from pgxc_class;
pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | nodeoids
---------+---------------+----------+-----------------+---------------+----------
24578 | H | 1 | 1 | 4096 | 16384
(1 row)
postgres=# select * from information_schema.tables where table_name = 'mutect';
table_catalog | table_schema | table_name | table_type | self_referencing_column_name | reference_generation | user_defined_type_catalog | user_defined_type_schema | user_defined_type_name | is_in
sertable_into | is_typed | commit_action
---------------+--------------+------------+------------+------------------------------+----------------------+---------------------------+--------------------------+------------------------+------
--------------+----------+---------------
postgres | staging | mutect | BASE TABLE | | | | | | YES
| NO |
(1 row)
postgres=# select * from pg_class where relname = 'mutect';
relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relpersistence |
relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl | reloptions
---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+----------------+-
--------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+--------+------------
mutect | 24576 | 24580 | 0 | 10 | 0 | 24578 | 0 | 0 | 0 | 24581 | 0 | f | f | p |
r | 26 | 0 | f | f | f | f | f | 10336 | |
(1 row)
It show up in all three tables. With confidence I then reran my copy command and to my great disappointment I received the same error:
\copy staging.mutect from '/tmp/20.mutect.call_stats.out';
ERROR: relation "mutect" does not exist
I am not a C programmer so I am at a loss here. I am guessing that COPY.h queries some table other than tables, pg_class or pgxc_class to get the relation information it needs to proceed and that is where the exception is being thrown. Does anyone on the team have any familiarity with this code so they could send me the table name?
Absent that, are there any other bulk loading utilities for Postgres-xc (even 3rd party apps) that might work for mr or should I revert to an earlier and possibly more stable version?
Thanks again,
Bill West
From: <West>, William West <ww...@uc...<mailto:ww...@uc...>>
Date: Monday, September 23, 2013 10:03 AM
To: Koichi Suzuki <koi...@gm...<mailto:koi...@gm...>>
Cc: "pos...@li...<mailto:pos...@li...>" <pos...@li...<mailto:pos...@li...>>
Subject: Re: [Postgres-xc-bugs] Copy Command
Thanks Koichi,
I checked pgxc_class on both nodes. The table appears in the node I created it as seen highlighted in this query result:
postgres=# select * from pgxc_class;
pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | nodeoids
---------+---------------+----------+-----------------+---------------+-------------
16387 | R | 0 | 0 | 0 | 16384
16396 | H | 1 | 1 | 4096 | 16384
16495 | H | 1 | 1 | 4096 | 16384 16385
16501 | H | 1 | 1 | 4096 | 16384 16385
16544 | H | 1 | 1 | 4096 | 16384 16385
24688 | R | 0 | 0 | 0 | 16384 16385
(6 rows)
When I look at my other node and run the same query I get:
postgres=# select * from pgxc_class;
pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | nodeoids
---------+---------------+----------+-----------------+---------------+-------------
16386 | H | 1 | 1 | 4096 | 16384
24603 | H | 1 | 1 | 4096 | 16385 16384
24609 | H | 1 | 1 | 4096 | 16385 16384
24652 | H | 1 | 1 | 4096 | 16385 16384
32820 | R | 0 | 0 | 0 | 16385 16384
I believe the highlighted table above is the same table. I can query it on either node however I notice that the pcrelid is different on each node. Is this significant?
Regards,
Bill West
From: Koichi Suzuki <koi...@gm...<mailto:koi...@gm...>>
Date: Sunday, September 22, 2013 6:17 PM
To: William West <ww...@uc...<mailto:ww...@uc...>>
Cc: "pos...@li...<mailto:pos...@li...>" <pos...@li...<mailto:pos...@li...>>
Subject: Re: [Postgres-xc-bugs] Copy Command
Sorry for the late response.
Could you check pgxc_class catalog to see if the table is registered to this catalog as well? Usually, if you've created the table with conventional CREATE TABLE command from one of the coordinators, the definition should have propagated to all the coordinators.
We're using COPY command in DBT-2 and does not have any significant problems.
---
Koichi Suzuki
2013/9/19 West, William <ww...@uc...<mailto:ww...@uc...>>
All,
I am attempting to use the copy command (as I previously did successfully in Postgres) to copy data from a file on the file system. When I try to upload data to the XC instance I get a 'relation does not exist' error. However if I check the metadata table, called tables, it is in there:
postgres=# select * from information_schema.tables where table_type = 'BASE TABLE';
table_catalog | table_schema | table_name | table_type | self_referencing_column_name | reference_generation | user_defined_type_catalog |
user_defined_type_schema | user_defined_type_name | is_insertable_into | is_typed | commit_action
---------------+--------------------+-------------------------+------------+------------------------------+----------------------+---------------------------+
--------------------------+------------------------+--------------------+----------+---------------
postgres | staging | mutect | BASE TABLE | | | |
| | YES | NO |
postgres | staging | vcf | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_features | BASE TABLE | | | |
| | YES | NO |
postgres | gene | vcf | BASE TABLE | | | |
| | YES | NO |
postgres | staging | source_downloads | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_cast | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_am | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_attrdef | BASE TABLE | | | |
| | YES | NO |
postgres | public | products2 | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_sizing_profiles | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_sizing | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_parts | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_packages | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_languages | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_implementation_info | BASE TABLE | | | |
| | YES | NO |
postgres | public | products | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_collation | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_seclabel | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_default_acl | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_table | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_group | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_node | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_class | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_server | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_data_wrapper | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_extension | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_ts_template | BASE TABLE | | | |
| | YES | NO |
postgres=# \copy staging.mutect from '/tmp/20.mutect.call_stats.out';
ERROR: relation "mutect" does not exist
Is this a known bug (version 1.0.3) or is there a different command for Copy in XC? If it is a bug is there any work around for bulk loading data?
Thanks,
Bill West
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Postgres-xc-bugs mailing list
Pos...@li...<mailto:Pos...@li...>
https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
|
|
From: West, W. <ww...@uc...> - 2013-09-23 17:09:10
|
Thanks Koichi,
I checked pgxc_class on both nodes. The table appears in the node I created it as seen highlighted in this query result:
postgres=# select * from pgxc_class;
pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | nodeoids
---------+---------------+----------+-----------------+---------------+-------------
16387 | R | 0 | 0 | 0 | 16384
16396 | H | 1 | 1 | 4096 | 16384
16495 | H | 1 | 1 | 4096 | 16384 16385
16501 | H | 1 | 1 | 4096 | 16384 16385
16544 | H | 1 | 1 | 4096 | 16384 16385
24688 | R | 0 | 0 | 0 | 16384 16385
(6 rows)
When I look at my other node and run the same query I get:
postgres=# select * from pgxc_class;
pcrelid | pclocatortype | pcattnum | pchashalgorithm | pchashbuckets | nodeoids
---------+---------------+----------+-----------------+---------------+-------------
16386 | H | 1 | 1 | 4096 | 16384
24603 | H | 1 | 1 | 4096 | 16385 16384
24609 | H | 1 | 1 | 4096 | 16385 16384
24652 | H | 1 | 1 | 4096 | 16385 16384
32820 | R | 0 | 0 | 0 | 16385 16384
I believe the highlighted table above is the same table. I can query it on either node however I notice that the pcrelid is different on each node. Is this significant?
Regards,
Bill West
From: Koichi Suzuki <koi...@gm...<mailto:koi...@gm...>>
Date: Sunday, September 22, 2013 6:17 PM
To: William West <ww...@uc...<mailto:ww...@uc...>>
Cc: "pos...@li...<mailto:pos...@li...>" <pos...@li...<mailto:pos...@li...>>
Subject: Re: [Postgres-xc-bugs] Copy Command
Sorry for the late response.
Could you check pgxc_class catalog to see if the table is registered to this catalog as well? Usually, if you've created the table with conventional CREATE TABLE command from one of the coordinators, the definition should have propagated to all the coordinators.
We're using COPY command in DBT-2 and does not have any significant problems.
---
Koichi Suzuki
2013/9/19 West, William <ww...@uc...<mailto:ww...@uc...>>
All,
I am attempting to use the copy command (as I previously did successfully in Postgres) to copy data from a file on the file system. When I try to upload data to the XC instance I get a 'relation does not exist' error. However if I check the metadata table, called tables, it is in there:
postgres=# select * from information_schema.tables where table_type = 'BASE TABLE';
table_catalog | table_schema | table_name | table_type | self_referencing_column_name | reference_generation | user_defined_type_catalog |
user_defined_type_schema | user_defined_type_name | is_insertable_into | is_typed | commit_action
---------------+--------------------+-------------------------+------------+------------------------------+----------------------+---------------------------+
--------------------------+------------------------+--------------------+----------+---------------
postgres | staging | mutect | BASE TABLE | | | |
| | YES | NO |
postgres | staging | vcf | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_features | BASE TABLE | | | |
| | YES | NO |
postgres | gene | vcf | BASE TABLE | | | |
| | YES | NO |
postgres | staging | source_downloads | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_cast | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_am | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_attrdef | BASE TABLE | | | |
| | YES | NO |
postgres | public | products2 | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_sizing_profiles | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_sizing | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_parts | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_packages | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_languages | BASE TABLE | | | |
| | YES | NO |
postgres | information_schema | sql_implementation_info | BASE TABLE | | | |
| | YES | NO |
postgres | public | products | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_collation | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_seclabel | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_default_acl | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_table | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_group | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_node | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pgxc_class | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_server | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_foreign_data_wrapper | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_extension | BASE TABLE | | | |
| | YES | NO |
postgres | pg_catalog | pg_ts_template | BASE TABLE | | | |
| | YES | NO |
postgres=# \copy staging.mutect from '/tmp/20.mutect.call_stats.out';
ERROR: relation "mutect" does not exist
Is this a known bug (version 1.0.3) or is there a different command for Copy in XC? If it is a bug is there any work around for bulk loading data?
Thanks,
Bill West
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
Postgres-xc-bugs mailing list
Pos...@li...<mailto:Pos...@li...>
https://lists.sourceforge.net/lists/listinfo/postgres-xc-bugs
|
10 messages has been excluded from this view by a project administrator.
