Bug #1906 UPDATEs of LONGBLOB > ~17 Megs fails with JDBC
Submitted: 20 Nov 2003 15:26 Modified: 28 Mar 2014 13:33
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
Category:Connector / J Severity:S2 (Serious)
Version:v3.0.9 OS:Linux (Redhat 8.0)
Assigned to: Alexander Soklakov CPU Architecture:Any

[20 Nov 2003 15:26] [ name withheld ]
MySQL v4.0.15-standard
JVM v1.4.1_05
OS Redhat v8.0

When trying to use a PreparedStatement to perform an UPDATE to a LONGBLOB > ~17 Megs, an SQLException of "Got error 127 from table handler" is received.  The /etc/my.cnf file reads:


Performing an INSERT INTO works fine (but of course, that's for creating new records, not updating existing ones).

I've attached a tar.gz file with my test program (w/ scripts to compile/run).  Inside is also the JDBC 2.0 & 3.0 jar files.  v2.0 fails at ~16M, but that is 'expected', hence the upgrade to '3.0'.

I've scoured the web to find a similar problem, but didn't come up with anything.  I can't imagine I'm the first to discover this, so I'm assuming I must be doing something wrong.  ;)

Thanks for your time,

How to repeat:
Run my Test program or a similar one.
[20 Nov 2003 15:31] [ name withheld ]
Test Files to duplicate the problem

Attachment: test.tar.gz (application/x-gzip, text), 3.16 KiB.

[20 Nov 2003 15:32] [ name withheld ]
I had to remove the JDBC jar files because they put me over the file size limit.
[25 Nov 2003 6:48] [ name withheld ]
Just did some further testing, and it fails at size = 16777181 in my example.  Taking into account the overhead for the WHERE portion of the query, all signs point to a 16M (16*1024*1024=16777216) limit on UPDATE commands.

I hope someone can look into this soon, or at least confirm it, so I don't think I'm going crazy.  :)

[25 Nov 2003 7:38] Mark Matthews
Please try a nightly build of Connector/J 3.0 from http://downloads.mysql.com/snapshots.php

I believe that I have fixed this problem in the development trees for 3.0 and 3.1.
[28 Mar 2014 13:33] Alexander Soklakov
Fixed in 3.0.10 and 3.1.1