Hi, Sergei.
Why does embedded fail while a normal client-server protocol is ok with that?
The difference is that the client check the server status twice during executeion - after the metadata reading and after the actual data. That SERVER_STATUS_CURSOR_EXISTS is returned on the 'reading data' stage and the usual client just skips it. But for the embedded server that status is same in both cases. And the 'reading metadata' part crashes when it sees that server status. It's in the prepare_to_fetch_result() called from mysql_stmt_execute(). I see no reason to store both statuses for the embedded server just to imitate the usual client's behaviour. It's better not to return the misleading status in this case. Best regards HF 18.03.2014 20:21, Sergei Golubchik wrote:
Hi, Holyfoot!
At file:///home/hf/wmar/mdev-5138/
------------------------------------------------------------ revno: 3995 revision-id: holyfoot@askmonty.org-20131209020845-9o3l30ao90vzf600 parent: holyfoot@askmonty.org-20131208143921-3veatgg9wngyzb47 committer: Alexey Botchkov <holyfoot@askmonty.org> branch nick: mdev-5138 timestamp: Mon 2013-12-09 06:08:45 +0400 message: MDEV-5138 Numerous test failures in "mtr --ps --embedded". If a prepared statement calls an stored procedure, the thd->server_status out of the SP goes up to the PS and then to the client. So that the client gets the SERVER_STATUS_CURSOR_EXISTS status if the SP uses a cursor. Which makes the embedded server fail. Why does embedded fail while a normal client-server protocol is ok with
On Dec 09, holyfoot@askmonty.org wrote: that?
Fixed by saving/restoring the upper-level server_status in sp_head::execute().
Regards, Sergei