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@xxxxxxxxx> 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@xxxxxxxxxxxxx
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
