The MySQL configuration variable max_allowed_packet controls how large a single MySQL protocol packet (not a network/TCP packet) can be. This variable can be changed to solve “Packet too large” errors typically caused by excessively long query strings, such as large multi-row INSERT statements. It’s both a session and global variable meaning that different sessions can set their own limits for for max_allowed_packet.

It’s often assumed that changing global variables in MySQL means that the value changes for each connection. However, in the case of max_allowed_packet and many others, the local setting of the variable is inherited from the global variable when a connection is first established. This has special implications when using connection pooling.

In a connection pooling environment, connections are pooled on the application server. When the application needs a connection to the MySQL server, it borrows it from the pool, and returns it when finished. Typically when a connection is borrowed from the pool, the connection pool library automatically calls its API’s variant of the “change user” API function (which uses the COM_CHANGE_USER protocol command) to reset some connection specific parameters.

The session-level max_allowed_packet setting for a connection is normally inherited from the global setting when a client first connects, but it isn’t copied when the user is changed. This means that even though the global max_allowed_packet may have been changed, the applications which are using those connections may not pick up the change until the connection pool’s connections are forced to reconnect, usually by restarting the application server.