Hey,
Below is a small test case demonstrating the issue. It selects “arr” column (
text[] ) from the “test” table. And you’ll see how the counter of SVs is
constantly increasing. If you just change “arr” to “id” (i.e., if you stop
retrieving the “arr” column from the table) you will see how the counter
increases and decreases (as a result of recycling) staying at the same level.
you need to have a “test” database and initialise it as so:
create table test ( id text, arr text[] );
insert into test values ( ‘a', '{"a","b","c"}' );
insert into test values ( ‘b', '{"a","b","c"}' );
insert into test values ( ‘c', '{"a","b","c"}' );
then the script itself:
<cut>
use strict;
use warnings;
use DBI;
use Devel::Leak;
my $dbh = DBI->connect( "dbi:Pg:dbname=test;host=localhost;port=5432",
"postgres", "" );
sub work {
my $sth = $dbh->prepare( "SELECT arr FROM test" );
$sth->execute();
my $r = $sth->fetchall_arrayref( {} );
}
while ( 1 ) {
my $handle;
my $count1 = Devel::Leak::NoteSV( $handle );
work();
my $count2 = Devel::Leak::NoteSV( $handle );
#print "diff: " . ( $count2 - $count1 ) . "\n";
print "c2: " . $count2 . "\n";
#sleep( 1 );
}
<cut>
Thank you,
K
On 2 Nov 2014, at 05:35, Ben Tilly <[email protected]> wrote:
> Honestly my best advice? Create a short stand alone script that can
> duplicate it.
>
> Create a temporary table, populate it, query it over and over again,
> and demonstrate the memory leak. With a clear test case, you're more
> likely to motivate someone to fix it.
>
> On Sat, Nov 1, 2014 at 5:20 PM, Krystian Samp <[email protected]> wrote:
>> Hello DBD-Pg!
>>
>> I've been struggling now for a few days with leaking memory in my long
>> running Perl script. Step by step I narrowed the source of the leak. And it
>> turned out to be the fetching of array ( text[] ) column from a postgresql
>> db. I tried: using fetchall_hashref( {} ), other variations of fetchall, all
>> variations of fetchrow_*, prepare vs prepare_cached, prepare+fetch_* vs
>> selectall_*. The result is always the same. If I remove the array column
>> from SELECT then the memory leak goes away. I detect the memory leak with
>> Devel::Monitor by comparing number of new SVs before and after the queries -
>> and I do it multiple times which shows that this number is only increasing
>> over time.
>>
>> I found few thread on the internet reporting some leaks related to
>> fetchall_* etc. but these didn't suggest any working solution.
>>
>> Is this a known problem? Am I doing something wrong? Would you have advice
>> how to fix it?
>>
>> Thank you in advance,
>> Kris
