| Bug #20072 | sleep(1) makes protocol error go away, with multi-statement query | ||
|---|---|---|---|
| Submitted: | 25 May 2006 18:29 | Modified: | 24 Jul 2006 9:18 |
| Reporter: | Timothy Smith | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server: C API (client library) | Severity: | S3 (Non-critical) |
| Version: | 5.0.22 | OS: | Linux (linux, freebsd, any) |
| Assigned to: | Magnus Blåudd | CPU Architecture: | Any |
[25 May 2006 18:30]
Timothy Smith
Test program; #define SLEEP_HACK 1 to see changed behavior
Attachment: mult_update.c (application/octet-stream, text), 2.39 KiB.
[25 May 2006 18:35]
Timothy Smith
See also bug #20070; fixing this may also fix that one.
[7 Jun 2006 13:11]
Magnus Blåudd
I supsect it is the server that disconnects the client when it's not doing anything for a while. Thus the client will reconnect before the next "question" to the server and during that process the buffers will have been flushed.
[21 Jul 2006 12:48]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/9414
[22 Jul 2006 15:58]
Konstantin Osipov
This is a duplicate of Bug#15752. Magnus, your patch is almost okay, but please review my patch, it's touches another place where we should check for mysql->server_status. Thanks. Chad, I'm stealing this.
[24 Jul 2006 9:18]
Magnus Blåudd
Duplicate of bug#15752. Reviewed, patch looks fine.
Description: When a multi-statement query is issued, but mysql_next_result() is not called, a protocol error results upon the next mysql_query() call. However, if sleep(1) is called before the next mysql_query(), the protocol error does not occur. This seems wrong, and I'm not aware of a reason that the sleep() should affect the exchange between client and server. Because of this, I suspect there may be some bug hiding in the client/server interaction in this case. How to repeat: See attached test program. As is, it will fail. If SLEEP_HACK is defined to 1, it it will work OK. Here is an example with #define SLEEP_HACK 0: $ ./mult_update iter 0: buf: 'update mult_update set f2 = 'test f2 0' where f1 = '0'; update mult_update set f3 = 'test f3 0' where f1 = 0' - A statement affected 0 row(s) iter 1: buf: 'update mult_update set f2 = 'test f2 1' where f1 = '1'; update mult_update set f3 = 'test f3 1' where f1 = 1' Packets out of order (Found: 2, expected 1) Program terminated at line 57: Lost connection to MySQL server during query Here is an example with #define SLEEP_HACK 1: $ ./mult_update iter 0: buf: 'update mult_update set f2 = 'test f2 0' where f1 = '0'; update mult_update set f3 = 'test f3 0' where f1 = 0' - A statement affected 0 row(s) Sleeping for 1 second... iter 1: buf: 'update mult_update set f2 = 'test f2 1' where f1 = '1'; update mult_update set f3 = 'test f3 1' where f1 = 1' skipped 52 bytes from file: socket (3) - A statement affected 0 row(s) Sleeping for 1 second... Suggested fix: Unknown.