Hitting MySQL max packet size limit

max_allowed_packet i think is the exact setting

[mysqld]
max_allowed_packet=16M

defaults to 16M, if needed you can bump this value up.

Note that there are two setting for this, one on the client (such as PHP) and one for the MySQL server (#1).

On shared hosting, you're not likely to be able to change this and I've run into situations where I've hit a 1MB limit.
(Site tried to cache something huge, which threw this max packet size error, which made the db go down, which watchdog tried to log to the db, which threw another error, which watchdog tried to log to the db... until PHP memory ran out).

The host wasn't too happy about increasing this limit either...

I'm getting this in D6.22. I have a lot of modules enabled, and alot of cck fields. I tried drupal tweaks module, but no luck. Im using plesk for hosting the site but don't seem to have access to the my.cnf file where I might be able to change this.

Not really familiar with plesk, somewhat familiar with cpanel (enough to know that i don't like it), but, you should have shell (ssh) access to your server. If so you can ssh to your server and you can typically find my.cnf in /etc/mysql/my.cnf.

So you could simple do:

sudo nano /etc/mysql/my.cnf

find and edit or insert the max_allowed_packet=[size] line, replacing [size] with the new size.

I hope it is not too late for me to add to this discussion and hopefully get some guidance.
I am getting the same error and am on a shared hosting plan. The host company refuse to alter this parameter for me so I am really stuck. The site performs very satisfactorily on the development machine.
Although the the error is quite messy, I thought I might paste it here because many of you have a lot more knowledge of databases than I do.

Error

SQL query:

INSERT INTO `cache_views` (`cid`, `data`, `expire`, `created`, `serialized`) VALUES ('views_data:en', 0x613a3137313a7b733a373a22776562666f726d223b613a323a7b733a353a227461626c65223b613a323a7b733a353a2267726f7570223b733a373a22576562666f726d223b733a343a226a6f696e223b613a313a7b733a343a226e6f6465223b613a333a7b733a31303a226c6566745f6669656c64223b733a333a226e6964223b733a353a226669656c64223b733a333a226e6964223b733a343a2274797065223b733a353a22494e4e4552223b7d7d7d733a363a22737461747573223b613a353a7b733a353a227469746c65223b733a363a22537461747573223b733a343a2268656c70223b733a33393a22546865206f70656e206f7220636c6f73656420737461747573206f66206120776562666f726d2e223b733a353a226669656c64223b613a323a7b733a373a2268616e646c6572223b733a33363a22776562666f726d5f68616e646c65725f6669656c645f776562666f726d5f737461747573223b733a31343a22636c69636b20736f727461626c65223b623a313b7d733a363a2266696c746572223b613a333a7b733a353a226c6162656c223b733a363a22537461747573223b733a373a2268616e646c6572223b733a33373a22776562666[...]

MySQL said: Documentation
#1153 - Got a packet bigger than 'max_allowed_packet' bytes

My question relates to the particular field of a table where it creates this error each time I try. To my eyes it seems to be in the cache_views table and the views_data field. Then this almighty slab of data is attempting to be inserted into it.
I have no idea what that data represents but I am wondering if I make another backup of the database on the development machine, then remove the data in that field, backup again and try importing that into the host database, is it likely that might work and then if so, what likely effect might it have in the site.
Then down the track, what are the implications in subsequent moving of data backwards and forwards between development and production environments.
I do empty the cache before backing up.
If my question is out of order here, I humbly apologise. I arrived here after searching on my error message and thought I had found the answer to my problems but then the host company upset my apple cart.
Perhaps it is a Views issue.

I was unable to resolve it, so I switched to Bluehost Pro plan and it disappeared.

Thank you for the reply dpatte, I have done the same thing, were very helpful, upped the parameter and all things went well.

Sounds like this is resolved.