- Create "--ps-protocol" and no "--<whatever>-protocol" variants of the former tests
t/grant_cache.test and t/query_cache_sql_prepare.test.
- Some additional subtest and fixes of bugs
- Minor improvements
This patch removes a false memory leak error report from the test suite.
There is a test case that puposely provokes a SAFEMALLOC leak report,
even though there is no actual leak.
bug #26842: master binary log contains invalid queries - replication fails
bug #12826: Possible to get inconsistent slave using SQL syntax Prepared Statements
Problem:
binlogging PS' we may produce syntacticly incorrect queries in the binlog replacing
some parameters with variable names (instead of variable values).
E.g. in the reported case of "limit ?" clause: replacing "?" with "@var"
produces "limit @var" which is not a correct SQL syntax.
Also it may lead to different query execution on slave if we
set and use a variable in the same statement, e.g.
"insert into t1 values (@x:=@x+1, ?)"
Fix: make the stored statement string created upon its execution use variable values
(instead of names) to fill placeholders.
CHECK OPTION and a subquery in WHERE condition.
The abort was triggered by setting the value of join->tables for
subqueries in the function JOIN::cleanup. This function was called
after an invocation of the JOIN::join_free method for subqueries
used in WHERE condition.
If a stored function or a trigger was killed it had aborted but no error
was thrown. This allows the caller statement to continue without a notice.
This may lead to a wrong data being inserted/updated to/deleted as in such
cases the correct result of a stored function isn't guaranteed. In the case
of triggers it allows the caller statement to ignore kill signal and to
waste time because of re-evaluation of triggers that always will fail
because thd->killed flag is still on.
Now the Item_func_sp::execute() and the sp_head::execute_trigger() functions
check whether a function or a trigger were killed during execution and
throws an appropriate error if so.
Now the fill_record() function stops filling record if an error was reported
through thd->net.report_error.
being used without being def
Inside method Item_func_unsigned::val_int, the variable value
can be returned without being initialized when the CAST argument
is of type DECIMAL and has a NULL value. This gives a run-time
error when building debug binaries using Visual C++ 2005.
Solution: Initialize value to 0
As MySQL character set tests can print results in many character sets
(latin1, utf8-8, sjis, cp932 and others) - its output can be incompatible
with the current locale settings, which makes PERL confuse.
Fix: reset LC_ALL and LC_CTYPE to "C", which is compatible with
any character set.
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
by other connections"
Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
Bug #25578 "CREATE TABLE LIKE does not require any privileges
on source table".
The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.
The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way.
Most of actual work for 5.1 was already done by fix for bug 20662 and
preliminary patch changing locking in ALTER TABLE.
The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
This patch solves this problem by adding privilege check, which was missing.
Finally it also removes some duplicated code from mysql_create_like_table()
and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with
TABLE_LIST::table_name".
Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
by other connections"
Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
Bug #25578 "CREATE TABLE LIKE does not require any privileges
on source table".
The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.
The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way (see
comment for sql_table.cc for details).
The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
This patch solves this problem by adding privilege check, which was missing.
Finally it also removes some duplicated code from mysql_create_like_table().
Note that, altough tests covering concurrency-related aspects of CREATE TABLE
LIKE behaviour will only be introduced in 5.1, they were run manually for
this patch as well.
Problem: Memory overrun happened in attempts to generate
error messages (e.g. in case of incorrect XPath syntax).
Reason: set_if_bigger() was used instead of set_if_smaller().
Change: replacing wrong set_if_bigger() to set_if_smaller(),
and making minor additional code clean-ups.
This patch corrects a problem encountered when reading the binlog from a remote
host. The application was crashing because the buffer variable (temp_buf) in
log_event was not pointing to the incoming data. For a normal file read, this
buffer is allocated by a previous call of read_log_event. However, when reading
from a remote host, the first call to read_log_event is not executed therefore
no buffer is allocated. Furthermore, there is no need to allocate a new buffer
because the incoming stream is what needs to be read.
This patch adds the call to initialize the temp_buf variable if reading from a
remote host. It also adds a check at destroy time to ensure the temp_buf is not
freed if reading from a remote host.
When processing the USE/FORCE index hints
the optimizer was not checking if the indexes
specified are enabled (see ALTER TABLE).
Fixed by:
Backporting the fix for bug 20604 to 5.0
mode.
When a new DATE/DATETIME field without default value is being added by the
ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't
checked whether such value was allowed by the set sql mode. Due to this
'0000-00-00' values was allowed for DATE/DATETIME fields even in the
NO_ZERO_DATE mode.
Now the mysql_alter_table() function checks whether the '0000-00-00' value
is allowed for DATE/DATETIME fields by the set sql mode.
The new error_if_not_empty flag is used in the mysql_alter_table() function
to indicate that it should abort if the table being altered isn't empty.
The new new_datetime_field field is used in the mysql_alter_table() function
for error throwing purposes.
The new error_if_not_empty parameter is added to the copy_data_between_tables()
function to indicate the it should return error if the source table isn't empty.
