Tom Lane wrote:
Stefan Kaltenbrunner <ste...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
