If I run the same code against a MySQL database (first arg dbi:mysql:database=blah, using DBD::mysql v2.9003), the memory consumption remains at its initial level.
The issue seems to have been reported before, even though in different variants. A patch has been posted on the CPAN page that seems to address only LOB handling, which clearly is not involved here. Tim responded to an earlier bug report there that he can't reproduce it.
I'm on Mac OSX Panther, using perl 5.8.1RC3 (the one that comes with the system), DBI 1.38, DBD::Oracle 1.15, and the Oracle client libraries from the Oracle preview for MacOSX (there's just one AFAIK: 9.2.0.1.0 Developer's release).
Is there a solution/fix/patch known already that escaped my attention?
Tim, if you can't reproduce this, I'd be perfectly willing to help track down the cause if you provide guidance as to how I would best go about this.
Thanks in advance for any help, suggestions, patch(es).
-hilmar -- ------------------------------------------------------------- Hilmar Lapp email: lapp at gnf.org GNF, San Diego, Ca. 92121 phone: +1-858-812-1757 -------------------------------------------------------------
use DBI;
my $dbh = DBI->connect($ARGV[0], $ARGV[1], $ARGV[2],
{ RaiseError=> 1, AutoCommit => 0, PrintError => 1 });
print "dropping possibly left over test table A1 ...\n";
eval {
$dbh->do("DROP TABLE A1");
};
print "\tfyi, table A1 doesn't exist yet\n" if $@;
print "creating test table ...\n";
$dbh->do('CREATE TABLE A1 (C1 INTEGER)');
my $sql = 'INSERT INTO A1 (c1) VALUES (?)';
print "about to insert 100k numbers with one statement:\n";
my $sth = $dbh->prepare($sql);
for (my $i = 1; $i < (1024*128); $i++) {
$sth->execute($i);
print "\t$i rows ...\n" if ($i % 5000) == 0;
}
print "done, committing this step\n";
$dbh->commit;$dbh->disconnect;
