Re: memory leak under heavy load? - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: memory leak under heavy load?
Date
Msg-id 20051129215035.GN78939@pervasive.com
Whole thread Raw
In response to Re: memory leak under heavy load?  (hubert depesz lubaczewski <depesz@gmail.com>)
Responses Re: memory leak under heavy load?  (hubert depesz lubaczewski <depesz@gmail.com>)
List pgsql-general
Are you sure this isn't just PostgreSQL caching data?

A complete testcase would help, too (ie: whatever you used to generate
the initial data).

On Tue, Nov 29, 2005 at 06:46:06PM +0100, hubert depesz lubaczewski wrote:
> On 11/29/05, hubert depesz lubaczewski <depesz@gmail.com> wrote:
> >
> > i think i've encountered a bug in postgresql 8.1.
> >
>
> now i'm nearly positive it's a bug.
>
> i created database in this way:
> CREATE DATABASE leak;
> \c leak
> CREATE TABLE users (id serial PRIMARY KEY, username TEXT NOT NULL DEFAULT
> '', password TEXT);
> then made a list of "usernames": from "aaaa" to "czzz" with probability 97%
> - 3% are missing.
> and then i COPY'ied this list into users.
>
> then:
> CREATE UNIQUE INDEX xxx on users (username);
> vacuum verbose analyze;
>
> after all of this i run this script:
> #!/usr/bin/perl
> use strict;
> use DBI;
>
> my $dbh = DBI->connect("dbi:Pg:dbname=leak", "pgdba", "", {"AutoCommit" =>
> 0,
>     "RaiseError" => 0, "PrintError" => 0}) or die "cannot connect\n";
>
> for (1..1000) {
>     my $i = 0;
>     my $q = "zzz";
>     while (1) {
>         $dbh->rollback();
>         $dbh->do("INSERT INTO users (username) VALUES ('$q')");
>         $dbh->commit();
>         $q++;
>         last if $q eq 'fzzz';
>         $i++;
>         if (0 == $i % 1000) {
>             system("ps uxf");
>         }
>     }
>     print "one iteration done\n";
>     <>;
> }
> $dbh->disconnect();
>
>
> technically - i think that after first "iteration" memory usage should not
> inreate. but it does.
> it does in small amounts, but still does.
> can anybody test/confirm the problem?
>
> depesz

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Question
Next
From: Janet Bagg
Date:
Subject: Re: errors with 8.1 make on Solari