Bug #84819 mysql_query/real_query is downloading the data
Submitted: 5 Feb 2017 3:04 Modified: 10 Apr 2017 13:18
Reporter: Martin Bonac Email Updates:
Status: Can't repeat Impact on me:
None 
Category:Connector / C Severity:S2 (Serious)
Version:5.7 OS:MacOS (10.12.3)
Assigned to: CPU Architecture:Any

[5 Feb 2017 3:04] Martin Bonac
Description:
mysql_query/real_query is downloading all the data, instead of mysql_store_result, or mysql_fetch_row after mysql_use_result.

How to repeat:
do a large select with mysql_query/real_query, watch your network and memory, then watch what happens after you use mysql_store_result, or mysql_fetch_row after mysql_use_result. mysql_query/real_query is doing the downloading. whats really weird is i was going to use mysql_store_result anyways, so the mysql_query/real_query downloads everything and gobbles up memory, then mysql_store_result returns immediately and just copies the data to yet another buffer as my memory doubles right after the call.

Suggested fix:
do what your docs say and don't download everything during mysql_query/real_query, as then both mysql_store_result/mysql_use_result becomes a really broken interface.
[6 Feb 2017 17:35] Martin Bonac
seems like specifying CLIENT_COMPRESS fixes this. if this is so, this can't be a optional flag, as it breaks the interface without it.
[9 Feb 2017 12:14] Chiranjeevi Battula
Hello Martin Bonac,

Thank you for the bug report.
Could you please provide repeatable test case (exact steps/sample code, create table statements/database details etc. - please make it as private if you prefer) to confirm this issue at our end?

Thanks,
Chiranjeevi.
[10 Feb 2017 2:19] Martin Bonac
{
      auto mySql = mysql_init(nullptr);
      
      mysql_real_connect(mySql, "host", "user", "password", nullptr, 0, nullptr, 0);
  
      mySql->reconnect = 1;
  
      mysql_select_db(mySql, "schema");
  
      auto statement =
        "SELECT * FROM table";
      mysql_real_query(mySql, statement, strlen(statement));/// Download happens, but i've noticed sometimes it partially downloads all the content
  
      mysql_close(mySql);
    }
[24 Mar 2017 11:10] Chiranjeevi Battula
Hello Martin Bonac,

Thank you for your feedback.
Could you please provide us full call stack (- please make it as private if you prefer) to confirm this issue at our end?

Thanks,
Chiranjeevi.
[27 Mar 2017 15:43] Martin Bonac
seems to always download something, but i've noticed that the faster your connection is, the less it tries to download. regardless this shows it downloading rows on a query

* thread #1: tid = 0x741b78, 0x000000010714c402 liblvphp.so`read_one_row [inlined] cli_safe_read(mysql=0x0000000104001200, is_data_packet="") at client.c:1187, queue = 'com.apple.main-thread', stop reason = breakpoint 5.1
  * frame #0: 0x000000010714c402 liblvphp.so`read_one_row [inlined] cli_safe_read(mysql=0x0000000104001200, is_data_packet="") at client.c:1187 [opt]
    frame #1: 0x000000010714c402 liblvphp.so`read_one_row(mysql=0x0000000104001200, fields=7, row=0x000000010300d748, lengths=0x000000010300d610) + 34 at client.c:2414 [opt]
    frame #2: 0x000000010714c313 liblvphp.so`cli_read_metadata_ex(mysql=<unavailable>, alloc=<unavailable>, field_count=<unavailable>, field=<unavailable>) + 179 at client.c:2247 [opt]
    frame #3: 0x000000010715286a liblvphp.so`cli_read_query_result [inlined] cli_read_metadata(mysql=0x0000000104001200, field_count=2, field=<unavailable>) + 730 at client.c:2282 [opt]
    frame #4: 0x000000010715285c liblvphp.so`cli_read_query_result(mysql=<unavailable>) + 716 at client.c:5194 [opt]
    frame #5: 0x00000001071505b5 liblvphp.so`mysql_real_query(mysql=0x0000000104001200, query=<unavailable>, length=<unavailable>) + 37 at client.c:5245 [opt]
...
[10 Apr 2017 13:18] Chiranjeevi Battula
Hello Martin Bonac,

Thank you for the feedback.
I tried to reproduce the issue at my end using MySQL Connector / C 6.1.9, MySQL 5.7.17 version.
If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.

Thanks,
Chiranjeevi.