The problem is that the query cache stores packets containing
the server status of the time when the cached statement was run.
This might lead to a wrong transaction status in the client side
if a statement is cached during a transaction and is later served
outside a transaction context (and vice-versa).
The solution is to take into account the transaction status when
storing in and serving from the query cache.
Bug#37671 crash on prepared statement + cursor + geometry + too many open files!
if mysql_execute_command() returns error then free materialized_cursor object.
is_rnd_inited is added to satisfy rnd_end() assertion
(handler may be uninitialized in some cases)
The code to get read the value of a system variable was extracting its value
on PREPARE stage and was substituting the value (as a constant) into the parse tree.
Note that this must be a reversible transformation, i.e. it must be reversed before
each re-execution.
Unfortunately this cannot be reliably done using the current code, because there are
other non-reversible source tree transformations that can interfere with this
reversible transformation.
Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the
functions operate). Added a cache of the value (so that it's constant throughout
the execution of the query). Note that the cache also caches NULL values.
Updated an obsolete related test suite (variables-big) and the code to test the
result type of system variables (as per bug 74).
Send_field.org_col_name has broken value on secondary execution.
It happens when result field is created from the field which belongs to view
due to forgotten assignment of some Send_field attributes.
The fix:
set Send_field.org_col_name,org_table_name with correct value during Send_field intialization.
Length value is the length of the field,
Max_length is the length of the field value.
So Max_length can not be more than Length.
The fix: fixed calculation of the Item_empty_string item length
(Patch applied and queued on demand of Trudy/Davi.)
Post-merge fix: mysql_client_test.c is compiled by C compilers
and some C compilers don't support mixed declarations and code
and it's explicitly forbidden by ISO C90.
There was a typo in a error check causing wrong thing to be ckecked
and a possible error not being caught.
Fixed by using the correct variable to test for malloc() errors.
the local tree contains a fix for
Bug#32748 "Inconsistent handling of assignments to
general_log_file/slow_query_log_file",
which changes output of a number of tests.
PREPARE", review fixes:
- make the patch follow the specification of WL#4166 and remove
the new error that was originally introduced.
Now the client never gets an error from reprepare, unless it failed.
I.e. even if the statement at hand returns a completely different
result set, this is not considered a server error.
The C API library, that can not handle this situation, was modified to
return a client error.
Added additional test coverage.
WL#4165 Prepared statements: validation
WL#4166 Prepared statements: automatic re-prepare
Fixes
Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE
Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes
Bug#27420 A combination of PS and view operations cause error + assertion on shutdown
The basic idea of the patch is to keep track of table metadata between
prepared statement prepare and execute. If some table used in the statement
has changed, the prepared statement is re-prepared before execution.
See WL#4165 and WL#4166 contents and comments in the code for details
of the implementation.
mysql_client_test causing a severe slowdown and increase
in memory usage, especially for test cases with long queries.
The solution is to enable the general log only in tests that
actually need the general log and disable it during the
execution of all other tests.
The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.
The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.
sporadically
Under some circumstances, the mysql_insert_id() value after SELECT ...
INSERT could return a wrong value. This could happen when the last
SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the
value of mysql_insert_id() was changed by some previous statements.
Fixed by checking the value of thd->insert_id_used in
select_insert::send_eof() and returning 0 for mysql_insert_id() if it
is not set.
