possible memory leak in 8.0 beta 1
This is under Windows 2000 SP4 using the beta1
installer package. If I create the following table:
CREATE TABLE test1
(
idnbr int4 NOT NULL,
num1 numeric(12,2),
num2 numeric(12,2),
text1 varchar(600),
CONSTRAINT test1_idnbr_key UNIQUE (idnbr)
)
WITH OIDS;
and then use the following perl script to generate a
test data insert script:
#!/usr/bin/perl -w
use strict;
my $ct=0;
open(FILE,">inserts.sql");
print FILE "truncate test1;\n";
print FILE "begin;\n";
while ($ct<100000)
{
print FILE "insert into test1(idnbr, num1, num2,
text1) values (";
print FILE $ct.",";
print FILE int(rand(100)).".".int(rand(100)).",";
print FILE int(rand(100)).".".int(rand(100)).",";
print FILE "'";
my $width = 20;
while ($width>0)
{
print FILE int(rand(999));
$width--;
}
print FILE "');"."\n";
$ct++;
}
print FILE "commit;\n";
close(FILE);
When I execute this script inside a fresh psql session
via "\i inserts.sql" I can watch the working set size
of the backend climb at a rate of approximately 500k
to 1meg per second up until the script finishes. At
this point, the backend servicing the psql session has
grown to have a working set size of almost 100 megs or
so. Executing the script a second time and/or
executing other commands in the same session after the
initial "bloating" period cause virtually no change in
the working set size of the backend.
I can replicate the behavior from both the 8.0 beta1
native win32 psql client and the cygwin 7.4.x psql
client.
Regards,
Shelby Cain
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
--- Shelby Cain <alyandon@yahoo.com> wrote:
[stuff about memory leaking snipped]
I see the following in the beta 2 changelog:
2004-08-25 15:43 tgl
* src/backend/: access/transam/xact.c,
utils/mmgr/portalmem.c, utils/resowner/README,
utils/resowner/resowner.c: Revise ResourceOwner code
to avoid accumulating ResourceOwner objects for every
command executed within a transaction. For long
transactions this was a significant memory leak.
Instead, we can delete a portal's or subtransaction's
ResourceOwner immediately, if we physically transfer
the information about its locks up to the parent
owner. This does not fully solve the leak problem; we
need to do something about counting multiple
acquisitions of the same lock in order to fix it. But
it's a necessary step along the way.
Is this what I'm seeing?
Regards,
Shelby Cain
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Import Notes
Resolved by subject fallback