possible memory leak in 8.0 beta 1

Started by Shelby Cainover 21 years ago3 messagesgeneral
Jump to latest
#1Shelby Cain
alyandon@yahoo.com

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

#2Shelby Cain
alyandon@yahoo.com
In reply to: Shelby Cain (#1)
Re: possible memory leak in 8.0 beta 1
--- 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

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Shelby Cain (#1)
Re: possible memory leak in 8.0 beta 1

Shelby Cain <alyandon@yahoo.com> writes:

This is under Windows 2000 SP4 using the beta1
installer package.

I believe this is fixed in beta2. It looks like the too-many-locks
problem ...

regards, tom lane