| Bug #2710 | max_allowed_packet=# | ||
|---|---|---|---|
| Submitted: | 11 Feb 2004 12:01 | Modified: | 4 Mar 2004 23:15 |
| Reporter: | Patrick Lanphier | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.0.17 | OS: | Linux (Linux 9.0) |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
[11 Feb 2004 12:14]
Dean Ellis
This is because you have set max_allowed_packet to 0, which you basically never actually want to do. Verifying, as we should probably force this to at least the minimum block size.
[12 Feb 2004 15:54]
Brian Aker
Better to toss an error then auto-fix it.
[4 Mar 2004 23:15]
Michael Widenius
I was not able to repat this in MySQL 4.0 or 4.1:
set max_allowed_packet=0; select @@max_allowed_packet;
-> 1024
SELECT CONCAT('My', 'S', 'QL');
-> MySQL
The only way I could find out how max_allowed_packet could be zero is if you set it on the command line to 0. I have now fixed that in MySQL 4.0 we ensure that max_allowed_packet is never smaller than 1024.
In MySQL 4.1 we will add warnings for all cases when max_allowed_packet is used to cut strings.
Description: If you set "set-variable = max_allowed_packet=#" concat stops functioning properly for instance "SELECT CONCAT('My', 'S', 'QL');" does not provide the correct result. How to repeat: set max_allowed_packet=# execute SELECT CONCAT('My', 'S', 'QL'); and incorrect result is provided for the query.