Re: Help with mysqlnd bug?
| From: | Andrey Hristov | Date: | Wed, 21 Sep 2016 16:45:59 +0000 |
| Subject: | Re: Help with mysqlnd bug? | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96069@lists.php.net to get a copy of this message | ||
Hi Richard,
On 21.09.2016 19:39, Fleshgrinder wrote:
On 9/21/2016 8:42 AM, Andrey Hristov wrote:this will be really nice. Have you tried with SELECT SLEEP(1000) or SELECT a FROM b UNION SELECT SLEEP(20)? And maybe mysqli_query with ASYNC and mysqli_poll can be used to be able to kill first connection from a second one, while the first does the long running query. Maybe the problem will manifest itself also in this case. In any case, I will need to reread mysqlnd's code to analyze it in my head where this comes from. But as I said, I need a bit of time. Best, AndreyHi Richard, On 20.09.2016 21:02, Fleshgrinder wrote:Hi Andrey, of course, of course. I only wrote you because it is seldom that there is feedback and this really needs fixing but if its today or next week shouldn't matter as long as it lands in one of the next releases. We reproduced it by an unbuffered query that selects a hug amount of data from the database and simply dropped the connection on the server side. However, it is not 100% reproducable in such cases. Sometimes absolutely nothing happens and PHP just ends the loop. Sometimes the warning from the PR appears. Sometimes a sleep in PHP after the loop over the unbuffered result set followed by a status call to the server reveals the actual error. It's weird and definitely requires more attention and we will continue to find better test cases. I'll talk to my friends on how to come up with a good test case that makes it reproducible in our automated tests in php-src.Hi Andrey! I am writing you because you are the last person with actual commits in the mysqlnd extension. I would like to ask if you could have a look at the following bug: - https://github.com/php/php-src/pull/2131 - https://bugs.php.net/bug.php?id=66370 This is a real problem for very long running queries and should definitely be fixed. Note that the patch from the actual bug report seems like the right fix and not the changes from the GitHub PR. Looking forward to your feedback, best regardsis it possible to wait until mid next week? I will try to reproduce it (I think a SELECT SLEEP(1000); will do the job too, and doesn't need fast reaction on the terminal :)). Best, Andrey