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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-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

Browse pgsql-committers by date

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

Browse pgsql-hackers by date

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