WL#1126: Handle gracefully long packets when using compressed protocol
Affects: Server-4.1
—
Status: Un-Assigned
This is to fix the problem described in BUG#1011: The idea is that the client should get 'ER_NET_PACKET_TOO_LARGE' when sending a long packet to the mysqld server. Currently it only works when using the normal (not compressed) protocol. When fixing this, one should be careful to only remove the logical packet that was too long, not any other packets. In other words, we can't just do a vio_read until there is no more data to get. The problem with removing the packet is that a compressed packet may include several normal packets. In other words, we have to uncompress data to read the real packet headers. The only file that needs to be changed is sql/net_serv.cc. One can test this by running 'perl tests/big_record.pl --compress' against a myslqd server started with --max_packet_length=8192 One should only get 'ER_NET_PACKET_TOO_LARGE' errors from the server, no 'server has gone away' errors. (One has to change the big_record.pl program slightly to ignore the above error). Proposed way to fix this: - Change net_realloc() to create a packet of up to '16*1024*1024+NET_HEADER_SIZE + COMP_HEADER_SIZE' when one uses the compressed protocol. (A compressed packet can't be more than 16M uncompressed) - In net_realloc() set net->error if packet is longer than net->max_packet_size and change the NET structure so that next packet will be read into net->buff+NET_HEADER_SIZE, overwriting the any data that is not in the header. - In my_net_read() (when handling compressed packets) should be changed so that when we got an error from net_realloc() we should ignore any not header data from the packet. (We need to store the header to be able to find the length of the packet we should ignore) - When returning from my_net_read() we should return packet_error if we got a too long packet. - It's ok for my_net_read() to set net->error to 0 when reading compressed data and use this to detect if we got a too big packet.
Copyright (c) 2000, 2024, Oracle Corporation and/or its affiliates. All rights reserved.