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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
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:40:04
Message-ID: 603c8f071001050940veb959b0j2fb76f3d76ec8657@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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?

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

...Robert

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2010-01-05 17:49:24 Re: Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial
Previous Message Tom Lane 2010-01-05 17:40:02 Re: [COMMITTERS] pgsql: Get rid of the need for manual maintenance of the initial

Browse pgsql-hackers by date

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