Update multi-query.xml

[miqrogroove]

Fixes #4778 by clarifying the MySQL "wait" happens after executing all queries.

[kamil-tekiela]

I don't think that's true. What evidence do you have for the contrary? Can you please share a reproducible on https://phpize.online/

[miqrogroove]

It's quite true. For my test case, I opened 2 separate connections. In PHP, I sent 3 insert queries via multi_query() and then used sleep(10) between each instance of next_result().

For simplicity, I opened the other connection on phpMyAdmin. I was able to refresh the target table immediately after starting the test in PHP, and all 3 records appeared in the database before the first sleep expired.

[kamil-tekiela]

It's quite true. For my test case, I opened 2 separate connections. In PHP, I sent 3 insert queries via multi_query() and then used sleep(10) between each instance of next_result().

For simplicity, I opened the other connection on phpMyAdmin. I was able to refresh the target table immediately after starting the test in PHP, and all 3 records appeared in the database before the first sleep expired.

Isn't this just a single result though? I'd imagine you need at 2 results to see the stall. For example:

SELECT 1, SLEEP(10);
SELECT 2, SLEEP(10);
INSERT INTO test VALUE (NOW());

The sleeps are irrelevant here, but I believe that the insert should wait for next_result. I can't test it now though.

[miqrogroove]

I tested this query and again all 3 records appeared instantly:

$sql = "
    INSERT INTO mytable SET name = 'hkjhkjh';
    SELECT * FROM mytable;
    INSERT INTO mytable SET name = 'hkjhkjh2';
    SELECT * FROM mytable;
    INSERT INTO mytable SET name = 'hkjhkjh3';
    SELECT * FROM mytable
";

This seems to support my revision. Even if I call sleep(10) and never call next_result() the server will process all of the queries.

[miqrogroove]

For clarity, I see MySQL also has a SLEEP function, which I am never using. I'm calling sleep in PHP to delay the result processing.

[kamil-tekiela]

Sorry for the delay, I forgot about this PR. You are right, the current paragraph is misleading. However, I decided to phrase it differently. Can you check if the PR #5380 is clear enough?