Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial
Date: 2010-01-05 17:49:24
Message-ID: 4B437BA4.90009@kaltenbrunner.cc (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Robert Haas wrote:
> On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
> <stefan(at)kaltenbrunner(dot)cc> wrote:
>> Tom Lane wrote:
>>> Log Message:
>>> -----------
>>> Get rid of the need for manual maintenance of the initial contents of
>>> pg_attribute, by having genbki.pl derive the information from the various
>>> catalog header files.  This greatly simplifies modification of the
>>> "bootstrapped" catalogs.
>>>
>>> This patch finally kills genbki.sh and Gen_fmgrtab.sh; we now rely
>>> entirely on
>>> Perl scripts for those build steps.  To avoid creating a Perl build
>>> dependency
>>> where there was not one before, the output files generated by these
>>> scripts
>>> are now treated as distprep targets, ie, they will be built and shipped in
>>> tarballs.  But you will need a reasonably modern Perl (probably at least
>>> 5.6) if you want to build from a CVS pull.
>> this broke the build on spoonbill:
>>
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2010-01-05%2015:05:08
>>
>> manually executing the command shows that the perl process eats more than
>> 250MB of RAM at closely afterwards fails with an out of memory due to
>> hitting the process limit on that box.
>> I don't think that is in any way sane :)
>>
>>
>> # perl -v
>> This is perl, v5.8.8 built for sparc64-openbsd
> 
> I just tried this with ulimit -v 131072 and it worked.  At 65536 and
> 32768 it emited an error about being unable to set the locale but
> still seemed to run.  At 32768 it couldn't load all its shared
> libraries any more so it croaked, but with a different error message.
> 
> Can we get the output of ulimit -a on that machine?

$ ulimit -a
time(cpu-seconds)    unlimited
file(blocks)         unlimited
coredump(blocks)     unlimited
data(kbytes)         524288
stack(kbytes)        4096
lockedmem(kbytes)    334589
memory(kbytes)       1000456
nofiles(descriptors) 128
processes            64


> 
> Is there by any chance some other, conflicting Catalog.pm on that machine?

as I said I can reproduce it manually withe the Catalog.pm from the 
failing build as well.
I can succeed building it using the root account but that runs the box 
more or less out of memory as it eats up to ~550MB RSS and 990MB of SIZE...



Stefan

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-05 17:51:48
Subject: Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial
Previous:From: Marko TiikkajaDate: 2010-01-05 17:45:30
Subject: Re: Writeable CTEs

pgsql-committers by date

Next:From: Tom LaneDate: 2010-01-05 17:51:48
Subject: Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial
Previous:From: Robert HaasDate: 2010-01-05 17:40:04
Subject: Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group