The problem is that unimplemented WIN32 version of pthread_kill
is returning ESRCH no matter the arguments, causing calls to
mysqld_list_processes to set the procinfo to dead because
pthread_kill returns non zero. The dead procinfo would show
up on a second invocation of show processlist.
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.
In cases when TRUNCATE was executed by invoking mysql_delete() rather
than by table recreation (for example, when TRUNCATE was issued on
InnoDB table with is referenced by foreign key) triggers were invoked.
In debug builds this also led to crash because of an assertion, which
assumes that some preliminary actions take place before trigger
invocation, which doesn't happen in case of TRUNCATE.
The fix is not to execute triggers in mysql_delete() when this
function is used by TRUNCATE.
Problem: if the IO slave thread is attempting to connect,
STOP SLAVE waits for the attempt to finish.
It may take a long time.
Fix: don't wait, stop the slave immediately.
Affected tests fixing. After the fix for st_relay_log_info::wait_for_pos() that
handles widely used select('master-bin.xxxx',pos) invoked by mysqltest
there appeared to be four tests that either tried synchronizing when
the slave was stopped or used incorrect synchronization method like
to call `sync_with_master' from the current connection being to the
master itself.
Fixed with correcting the current connection or/and using the correct
synchronization macro when possible.
MASTER_POS_WAIT return values are different than expected when the server is not a slave.
It returns -1 instead of NULL.
Fixed with correcting st_relay_log_info::wait_for_pos() to return the proper
value in the case of rli info is not inited.
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.
It's impossible to determine which test inside mysql_client_test
failed if the log file is overwritten by mysqltest when dumping
the test case results. Redirect mysql_client_test output to a
separate file.
- Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
to before the late NULLs filtering code.
- Backport function comments from 6.0.
with errno 17
my_create() did not perform any checks for the case when a file is
successfully created by a call to open(), but the call to
my_register_filename() later fails because the number of open files
has exceeded the my_open_files limit. This can happen on platforms
which do not have getrlimit(), and hence we do not know the real limit
for open files. In such a case an error was returned to a caller
although the file has actually been created. Since callers assume
my_create() to return an error only when it failed to create a file,
they did not perform any cleanups, leaving an 'orphaned' file on the
file system.
Fixed by adding a check for the above case to my_create() and ensuring
the newly created file is deleted before returning an error.
Creating a deterministic test case in the test suite is impossible,
because the exact steps required to reproduce the above situation
depend on the platform and/or environment (OS per-user limits, queries
executed by previous tests, startup parameters). The patch was
manually tested on Windows using examples posted in the bug report.
and Item_direct_ref constructor calls.
Order of ref->field_name and ref->table_name arguments
is of Item_ref and Item_direct_ref in the fix_inner_refs
function is inverted.
added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of mysql data home directory in
DATA DIRECTORY & INDEX DIRECTORY is disallowed.
Assertion `0' failed
If ROW item is a part of an expression that also has
aggregate function calls (COUNT/SUM/AVG...), a
"splitting" with an Item::split_sum_func2 function
is applied to that ROW item.
Current implementation of Item::split_sum_func2
replaces this Item_row with a newly created
Item_aggregate_ref reference to it.
Then the row cache tries to work with the
Item_aggregate_ref object as with the Item_row object:
row cache calls row-emulation methods such as cols and
element_index. Item_aggregate_ref (like it's parent
Item_ref) inherits dummy implementations of those
methods from the hierarchy root Item, and call to
them leads to failed assertions and wrong data
output.
Row-emulation virtual functions (cols, element_index, addr,
check_cols, null_inside and bring_value) of Item_ref have
been overloaded to forward calls to an underlying item
reference.
The problem is that passing anything other than a integer to a limit
clause in a prepared statement would fail. This limitation was introduced
to avoid replication problems (e.g: replicating the statement with a
string argument would cause a parse failure in the slave).
The solution is to convert arguments to the limit clause to a integer
value and use this converted value when persisting the query to the log.
NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was
not seen as constant, but as FUNCTION_UNARY_MINUS(constant)
while we are at the same time pretending it was a basic const
item. This confused the aggregate handlers in exciting ways.
We now make NAME_CONST() behave more consistently.
Was a double-free of the Unique member of Item_func_group_concat.
This was not causing a crash because the Unique is a descendent of
Sql_alloc.
Fixed to free the Unique only if it was allocated for the instance
of Item_func_group_concat it was referenced from
