Prev: Writeable CTEs
Next: We no longer have a fallback for machines without working int64
From: Stefan Kaltenbrunner on 5 Jan 2010 14:23
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(a)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
From: Stefan Kaltenbrunner on 5 Jan 2010 14:43
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> writes:
>> 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.
>
> What about Alvaro's idea of adding
>
> $row = undef;
>
> at the bottom of the loop? That seems marginally less ugly...

not sure I want to argue about the ugliness of perl but that has the
same effect as my patch so either way would do to get spoonbill green again.

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: Writeable CTEs
Next: We no longer have a fallback for machines without working int64