From: Pete Gamache <gamache@cpan.org>
Date: Fri, 9 Oct 2009 20:32:04 +0000 (+0000)
Subject: added troubleshooting case of excessive memory allocation involving TEXT/BLOB/etc
X-Git-Tag: v0.08113~38
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=d50421e7ae5f77fd0c51e74943ca3aea078901eb;p=dbsrgits%2FDBIx-Class.git

added troubleshooting case of excessive memory allocation involving TEXT/BLOB/etc
columns and large LongReadLen
---

diff --git a/lib/DBIx/Class/Manual/Troubleshooting.pod b/lib/DBIx/Class/Manual/Troubleshooting.pod
index e3b1ab3..56bcc01 100644
--- a/lib/DBIx/Class/Manual/Troubleshooting.pod
+++ b/lib/DBIx/Class/Manual/Troubleshooting.pod
@@ -156,5 +156,16 @@ L<https://bugzilla.redhat.com/show_bug.cgi?id=379791>,
 L<https://bugzilla.redhat.com/show_bug.cgi?id=460308> and
 L<http://rhn.redhat.com/errata/RHBA-2008-0876.html>
 
+=head2 Excessive Memory Allocation with TEXT/BLOB/etc. Columns and Large LongReadLen
+
+It has been observed, using L<DBD::ODBC>, that a creating a L<DBIx::Class::Row> 
+object which includes a column of data type TEXT/BLOB/etc. will allocate 
+LongReadLen bytes.  This allocation does not leak, but if LongReadLen 
+is large in size, and many such row objects are created, e.g. as the 
+output of a ResultSet query, the memory footprint of the Perl interpreter 
+can grow very large.
+
+The solution is to use the smallest practical value for LongReadLen.
+
 =cut