Le 28 mai 06 à 04:08, Andrew Dunstan a écrit :
> Tom Lane wrote:
>> "osprey" hasn't been able to build HEAD since the GIN code was added.
>> I'm not sure that GIN is really to blame though, as the error looks
>> like an out-of-memory problem while trying to link the backend:
>> ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
>> -Wendif-labels -fno-strict-aliasing -g -L../../src/port -Wl,-R'/
>> data/postgresql/buildfarm/workdir/HEAD/inst/lib' -Wl,-E access/
>> SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o
>> commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o
>> main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o
>> postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/
>> SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/
>> SUBSYS.o ../../src/port/libpgport_srv.a -lintl -lcrypt -lm -o
>> ld in malloc(): error: brk(2) failed [internal error]
>> gcc: Internal error: Abort trap (program ld)
>> Please submit a full bug report.
>> See <URL:http://www.netbsd.org/Misc/send-pr.html> for instructions.
>> gmake: *** [postgres] Error 1
>> Perhaps the swap space or ulimit setting on the box needs to be
I don't think it's a swap problem. I've not seen the machine go much
in the swap while running the build, but I've not checked since the
I was sort of hoping the issue will resovle itself when the size of
the link would change again...
What kind of ulimit did you think of ?
I'll try upping the data segment size.
> Or maybe ccache is the culprit - there have been suspicions before
> that ccache is responsible for errors, but it's never been
> confirmed. Remi, can you try turning it off and see what happens?
> just comment out the CC => "cache gcc" line in the config file.
I'll try that.
In response to
pgsql-hackers by date
|Next:||From: Marko Kreen||Date: 2006-05-28 11:45:39|
|Subject: Re: Inefficient bytea escaping?|
|Previous:||From: Tom Lane||Date: 2006-05-28 05:00:18|
|Subject: Re: [HACKERS] psql \copy warning |