• unknown's avatar
    A fix and a test case for Bug#15752 "Lost connection to MySQL server · 36510232
    unknown authored
    when calling a SP from C API"
    
    The bug was caused by lack of checks for misuse in mysql_real_query. 
    A stored procedure always returns at least one result, which is the 
    status of execution of the procedure itself.
    This result, or so-called OK packet, is similar to a result
    returned by INSERT/UPDATE/CREATE operations: it contains the overall
    status of execution, the number of affected rows and the number of
    warnings. The client test program attached to the bug did not read this 
    result and ivnoked the next query. In turn, libmysql had no check for 
    such scenario and mysql_real_query was simply trying to send that query 
    without reading the pending response, thus messing up the communication
    protocol.
    
    The fix is to return an error from mysql_real_query when it's called
    prior to retrieval of all pending results.
    
    
    client/mysqlbinlog.cc:
      net_safe_read -> cli_safe_read
    include/mysql.h:
      Remove a private function from the public header.
    include/mysql_com.h:
      Remove a define that is never used.
    include/sql_common.h:
      Add a declaration for cli_safe_read - a function that reads one packet
      from the server.
    libmysql/libmysql.c:
      net_safe_read -> cli_safe_read
      Return CR_COMMANDS_OUT_OF_SYNC on attempt to execute a statement
      using a connection which has pending result sets.
    sql-common/client.c:
      Actual fix for Bug#15752: if the server has pending result sets for
      the client, return CR_COMMANDS_OUT_OF_SYNC on attempt to execute
      another query. Similarly to the behaviour of mysql_use_result(),
      multiple result sets block the connection and must be fetched
      before it can be used for another query.
      This uncovered an error in the protocol: the server doesn't drop
      SERVER_MORE_RESULTS_EXISTS status flag upon an error, so in case of
      a multi-query like SELECT 1; SELECT syntax_error; SELECT 2; 
      the client has no way to know that the server won't ever come to 
      execution of the third query and won't return any result sets for it.
      For now, fix it in cli_safe_read, as a proper fix requires extension
      of the client-server protocol.
    sql/protocol.cc:
      Remove a name that is never used.
    sql/slave.cc:
      net_safe_read -> cli_safe_read
    tests/mysql_client_test.c:
      Make 'query' a local variable to avoid name clash.
      Add a test case for Bug#15752 "Lost connection to MySQL server when
      calling an SP from C API"
    36510232
slave.cc 166 KB