[CONC-68] SELECT fails with "Got packet bigger than 'max_allowed_packet'" on a table with longblob column with fields greater than 15MB Created: 2014-01-23  Updated: 2014-01-24  Resolved: 2014-01-24

Status: Closed
Project: MariaDB Connector/C
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Sudhindra Bhat Assignee: Georg Richter
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows , MariaDB Client library for C - Rev 110



 Description   

SELECT fails with "Got packet bigger than 'max_allowed_packet'" on a table with longblob column with field greater than 17MB.

max_allowed_packet = 50MB in the server. The same query runs successfully using MySQL C connector.

In mthd_my_read_query_result() , net_safe_read() returns -1 after setting error 2020.



 Comments   
Comment by Sudhindra Bhat [ 2014-01-23 ]

MySQL docs at http://dev.mysql.com/doc/refman/5.0/en/c-api.html states "The default maximum built into the client library is 1GB". We did not have to set client max_allowed_packet explicitly when working with Oracle's API. Do we need to set it explicitly with MariaDB API?

Comment by Peter Laursen [ 2014-01-23 ]

I have a comment:

Don't confuse with the CLI that has a 16MB default for max_allowed packet
(refer http://dev.mysql.com/doc/refman/5.6/en/mysql-command-options.html#option_mysql_max_allowed_packet).
.. but the API has (should have) a default of 1GB for max_allowed_packet.

If the MariaDB API does not have a default of 1 GB like the Oracle API has, it is an extremely dangerous incompatible (and undocumented, I think) change IMO. For instance a backup tool created with the API could create an incomplete backup - resulting in data loss after restore.

Comment by Georg Richter [ 2014-01-24 ]

Fxed in rev. 111

Comment by Sudhindra Bhat [ 2014-01-24 ]

not fixed: rev. 111 returns error 2000.

mthd_my_read_rows() sets CR_UNKNOWN_ERROR.

Generated at Thu Feb 08 03:02:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.