-
Anushree Prakash B authored
PROCEDURE, IF THE RESULT SET IS EMPTY. Description: ============ When executing a prepared statement with a procedure call with CURSOR_TYPE_READ_ONLY flag set, libmysqlclient hangs when the procedure performs a SELECT query that returns an empty result set. Analysis: ========= Generally, metadata result sets are no longer terminated with EOF(now OK) packet. However, we have an exception when a cursor is opened by the server in which case we can have a metadata packet terminated by an EOF(now OK) packet. For a simple SELECT query prepared to be executed, when a client requests a cursor to be opened, the server can decide to either open a cursor or send the result set rows. 1. If no cursor is opened by the server, the packet sequence is -> <metadata><0 or more rows><OK> 2. If server opens a cursor, the packet sequence is <metadata><OK><0 or more rows><OK> The hang in the bug report happens for cases when the server doesn't open a cursor and we have an empty result set. In this case, the packet sequence sent by the server is <metadata><OK>. Client should be able to figure out that the OK packet following the metadata is the last OK packet of the sequence and it indicates the end of rows result-set. Hence, it need not perform any additional reads which can cause such hangs. Fix: ==== The solution is to check whether the server responded with cursor or not and perform packet reads accordingly.
Anushree Prakash B authoredPROCEDURE, IF THE RESULT SET IS EMPTY. Description: ============ When executing a prepared statement with a procedure call with CURSOR_TYPE_READ_ONLY flag set, libmysqlclient hangs when the procedure performs a SELECT query that returns an empty result set. Analysis: ========= Generally, metadata result sets are no longer terminated with EOF(now OK) packet. However, we have an exception when a cursor is opened by the server in which case we can have a metadata packet terminated by an EOF(now OK) packet. For a simple SELECT query prepared to be executed, when a client requests a cursor to be opened, the server can decide to either open a cursor or send the result set rows. 1. If no cursor is opened by the server, the packet sequence is -> <metadata><0 or more rows><OK> 2. If server opens a cursor, the packet sequence is <metadata><OK><0 or more rows><OK> The hang in the bug report happens for cases when the server doesn't open a cursor and we have an empty result set. In this case, the packet sequence sent by the server is <metadata><OK>. Client should be able to figure out that the OK packet following the metadata is the last OK packet of the sequence and it indicates the end of rows result-set. Hence, it need not perform any additional reads which can cause such hangs. Fix: ==== The solution is to check whether the server responded with cursor or not and perform packet reads accordingly.
Loading