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

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> did that and it seems the problem is in the loop that does:
>
>> foreach my $row (@$data)
>> {
>
>>      # To construct fmgroids.h and fmgrtab.c, we need to inspect some
>>      # of the individual data fields.  Just splitting on whitespace
>
> Huh.  It's weird that I don't see a leak in either 5.8.7 or 5.10.1,
> which are the two closest perl versions I have handy here.  I think
> this may be a platform-specific Perl bug.  Still, it would be nice
> to work around it if we can.

yeah it is probably some strange platform specific issue - however with
some help from the IRC channel I came up with the following patch that
considerable reduces the memory bloat (but still needs ~55MB max) and
allows the build to succeed.


>
> I'm not nearly good enough in Perl to be sure about the semantics
> of this loop.  Is it possible that it's changing the global contents
> of the @$data structure, rather than just hacking a local copy of
> each row before pushing some values into @fmgr?

hmm it is leaking a constant amount of 240kbyte per loop iteration with
the original code but yeah very weird issue...


Stefan
Index: src/backend/utils/Gen_fmgrtab.pl
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/utils/Gen_fmgrtab.pl,v
retrieving revision 1.4
diff -u -r1.4 Gen_fmgrtab.pl
--- src/backend/utils/Gen_fmgrtab.pl    5 Jan 2010 01:06:56 -0000    1.4
+++ src/backend/utils/Gen_fmgrtab.pl    5 Jan 2010 19:14:10 -0000
@@ -56,7 +56,7 @@
 }

 my $data = $catalogs->{pg_proc}->{data};
-foreach my $row (@$data)
+while( my $row = shift @$data )
 {

     # To construct fmgroids.h and fmgrtab.c, we need to inspect some