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

Robert Haas wrote:
> On Tue, Jan 5, 2010 at 12:24 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.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