MySQL uses two source layouts when building : the bzr
layout and the source package layout.
The previous fix for bug 35250 contained 1 change that is
valid for both modes and a number of changes that are valid
only for the bzr source layout.
The important thing was to fix the source package layout.
And for this the change in configure.in was sufficient.
It's not trivial (and not requested by this bug) to support
VPATH builds from the bzr trees.
This is why the other changes are reverted and the change to
fix the VPATH build for source distributions is left intact.
The test case added in previous patch missed a RESET MASTER on
test start up. Without it, showing binary log contents can
sometimes show spurious entries from previously executed tests,
ultimately causing test failure - result mismatch.
The test file was added in:
revid:luis.soares@sun.com-20100224190153-k0bpdx9abe88uoo2
This patch also moves the test case into binlog_innodb_row.test
file. This way we avoid having yet another test file,
binlog_row_innodb_truncate.test, whose only purpose is to host
one test case. This had been actually suggested during original
patch review, but somehow the binlog_innodb_row was missed when
searching for a file to host the test case.
The problem is that not all column names retrieved from a SELECT
statement can be used as view column names due to length and format
restrictions. The server failed to properly check the conformity
of those automatically generated column names before storing the
final view definition on disk.
Since columns retrieved from a SELECT statement can be anything
ranging from functions to constants values of any format and length,
the solution is to rewrite to a pre-defined format any names that
are not acceptable as a view column name.
The name is rewritten to "Name_exp_%u" where %u translates to the
position of the column. To avoid this conversion scheme, define
explict names for the view columns via the column_list clause.
Also, aliases are now only generated for top level statements.
mysql-test/include/view_alias.inc:
Add test case for Bug#40277
mysql-test/r/compare.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/group_by.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/ps.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/subselect3.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/type_datetime.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/union.result:
Bug#40277: SHOW CREATE VIEW returns invalid SQL
mysql-test/r/view.result:
Add test case result for Bug#40277
mysql-test/r/view_alias.result:
Add test case result for Bug#40277
mysql-test/t/view_alias.test:
Add test case for Bug#40277
sql/sql_view.cc:
Check if auto generated column names are conforming. Also, the
make_unique_view_field_name function is not used as it uses the
original name to construct a new one, which does not work if the
name is invalid.
The problem was that bits of the destructive equality propagation
optimization weren't being undone after the execution of a stored
program. Modifications to the parse tree that are based on transient
properties must be undone to enable the re-execution of stored
programs.
The solution is to cleanup any references to predicates generated
by the equality propagation during the execution of a stored program.
mysql-test/r/trigger.result:
Add test case result for Bug#51650.
mysql-test/t/trigger.test:
Add test case for Bug#51650.
sql/item.cc:
Remove reference to a equality predicate.
Spatial indexes were not checking for out-of-record condition in
the handler next command when the previous command didn't found
rows.
Fixed by making the rtree index to check for end of rows condition
before re-using the key from the previous search.
Fixed another crash if the tree has changed since the last search.
Added a test case for the other error.
consider clustered primary keys
Choosing a shortest index for the covering index scan,
the optimizer ignored the fact, that the clustered primary
key read involves whole table data.
The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.
mysql-test/r/innodb_mysql.result:
Test case for bug #39653.
mysql-test/t/innodb_mysql.test:
Test case for bug #39653.
sql/sql_select.cc:
Bug #39653: find_shortest_key in sql_select.cc does not
consider clustered primary keys
The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.
+ failing statements
Implicit DROP event for temporary table is not getting
LOG_EVENT_THREAD_SPECIFIC_F flag, because, in the previous
executed statement in the same thread, which might even be a
failed statement, the thread_specific_used flag is set to
FALSE (in mysql_reset_thd_for_next_command) and not set to TRUE
before connection is shutdown. This means that implicit DROP
event will take the FALSE value from thread_specific_used and
will not set LOG_EVENT_THREAD_SPECIFIC_F in the event header. As
a consequence, mysqlbinlog will not print the pseudo_thread_id
from the DROP event, because one of the requirements for the
printout is that this flag is set to TRUE.
We fix this by setting thread_specific_used whenever we are
binlogging a DROP in close_temporary_tables, and resetting it to
its previous value afterward.
If an outer query is broken, a subquery might not even get set up.
EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
of the half-setup info.
We now catch this case and print as much as we have, as it doesn't cost us
anything (doesn't make regular execution slower).
backport from 5.1
mysql-test/r/explain.result:
Show that EXPLAIN EXTENDED with subquery and illegal out query doesn't crash.
Show also that SHOW WARNINGS will render an additional Note in the hope of
being, well, helpful.
mysql-test/t/explain.test:
If we have only half a query for EXPLAIN EXTENDED to print (i.e.,
incomplete subquery info as outer query is illegal), we should
provide the user with as much info as we easily can if they ask
for it. What we should not do is crash when they come asking for
help, that violates etiquette in some countries.
sql/item_subselect.cc:
If the sub-query's actually set up, print it. Otherwise, elide.
START SLAVE UNTIL MASTER ... specifies only SQL thread to stop.
rpl_slave_skip erronously deployed waiting for stop of both threads.
Corrected with deploying the correct macro.
Notice, earlier a similar bug@47749 was fixed in mysql-trunk.
mysql-test/suite/rpl/t/rpl_slave_skip.test:
changing two waiting calls for offline of both threads into waiting for SQL to stop.
for same data when using bit fields
Problem: checksum for BIT fields may be computed incorrectly
in some cases due to its storage peculiarity.
Fix: convert a BIT field to a string then calculate its checksum.
mysql-test/r/myisam.result:
Fix for bug#51304: checksum table gives different results
for same data when using bit fields
- test result.
mysql-test/t/myisam.test:
Fix for bug#51304: checksum table gives different results
for same data when using bit fields
- test case.
sql/sql_table.cc:
Fix for bug#51304: checksum table gives different results
for same data when using bit fields
- convert BIT fields to strings calculating its checksums
as some bits may be saved among NULL bits in the record buffer.
Item_field::print method does not take into
account fields whose values may be null.
The fix is to print 'NULL' if field value is null.
mysql-test/r/explain.result:
test case
mysql-test/r/func_str.result:
result fix
mysql-test/r/having.result:
result fix
mysql-test/r/select.result:
result fix
mysql-test/r/subselect.result:
result fix
mysql-test/r/union.result:
result fix
mysql-test/t/explain.test:
test case
sql/item.cc:
print 'NULL' if field value is null.
The problem was that the CSV storage engine does not support NULL
fields, yet in some early 5.1 version the log tables (general_log
and slow_log) were created with null fields. On top of this, when
altering a CSV table column, all fields of the table must be NOT
NULL otherwise the alteration fails.
The solution is to ensure that during upgrade all columns of the
log tables are NOT NULL.
mysql-test/r/log_tables_upgrade.result:
Add test case result for Bug#49823.
mysql-test/std_data/bug49823.CSV:
Sample data for test.
mysql-test/std_data/bug49823.frm:
Add a CSV table which mimics the general_log table, except that
it contains a nullable column.
mysql-test/t/log_tables_upgrade.test:
Add test case for Bug#49823.
scripts/mysql_system_tables_fix.sql:
Ensure that all columns of the log tables are NOT NULL.
The test failed due to Bug #29790.
However, logics of the failing part does not need I_S selecting.
Fixing to remove the non-deterministic I_S selecting as redundant
from a part of the test dealing with BUG@22864.
mysql-test/suite/rpl/r/rpl_row_create_table.result:
results updated.
mysql-test/suite/rpl/t/disabled.def:
rpl_row_create_table is re-enabled.
mysql-test/suite/rpl/t/rpl_row_create_table.test:
removed a non-deterministic I_S selecting as redundant
from a part of the test dealing with BUG@22864.
The problem is that cond->fix_fields(thd, 0) breaks
condition(cuts off 'having'). The reason of that is
that NULL valued Item pointer is present in the
middle of Item list and it breaks the Item processing
loop.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/item_cmpfunc.h:
added ASSERT to make sure that we do not add NULL valued Item pointer
sql/sql_select.cc:
skip adding an item to condition if Item pointer is NULL.
skip adding a list to condition if this list is empty.
performance degradation.
Filesort + join cache combination is preferred to full index scan because it
is usually faster. But it's not the case when the index is clustered one.
Now test_if_skip_sort_order function prefers filesort only if index isn't
clustered.
mysql-test/r/innodb_mysql.result:
Added a test case for the bug#50843.
mysql-test/t/innodb_mysql.test:
Added a test case for the bug#50843.
sql/sql_select.cc:
Bug#50843: Filesort used instead of clustered index led to
performance degradation.
Now test_if_skip_sort_order function prefers filesort only if index isn't
clustered.
Detailed revision comments:
r6538 | sunny | 2010-01-30 00:43:06 +0200 (Sat, 30 Jan 2010) | 6 lines
branches/5.1: Check *first_value every time against the column max
value and set *first_value to next autoinc if it's > col max value.
ie. not rely on what is passed in from MySQL.
[49497] Error 1467 (ER_AUTOINC_READ_FAILED) on inserting a negative value
rb://236
Detailed revision comments:
r6536 | sunny | 2010-01-30 00:13:42 +0200 (Sat, 30 Jan 2010) | 6 lines
branches/5.1: Check *first_value everytime against the column max
value and set *first_value to next autoinc if it's > col max value.
ie. not rely on what is passed in from MySQL.
[49497] Error 1467 (ER_AUTOINC_READ_FAILED) on inserting a negative value
rb://236
Propagation of a large unsigned numeric constant
in the WHERE expression led to wrong result.
For example,
"WHERE a = CAST(0xFFFFFFFFFFFFFFFF AS USIGNED) AND FOO(a)",
where a is an UNSIGNED BIGINT, and FOO() accepts strings,
was transformed to "... AND FOO('-1')".
That has been fixed.
Also EXPLAIN EXTENDED printed incorrect numeric constants in
transformed WHERE expressions like above. That has been
fixed too.
mysql-test/r/bigint.result:
Added test case for bug #45360.
mysql-test/t/bigint.test:
Added test case for bug #45360.
sql/item.cc:
Bug #45360: wrong results
As far as Item_int_with_ref (and underlaying Item_int)
class accepts both signed and unsigned 64bit values,
Item_int::val_str and Item_int::print methods have been
modified to take into account unsigned_flag.
The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.
Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().
mysql-test/r/join.result:
Added a test case for bug #50335.
mysql-test/t/join.test:
Added a test case for bug #50335.
sql/sql_select.cc:
Removing the assertion in eq_ref_table() as it does not make
any sense. We also have to take care of the 'found' counter so
that we count multiple references only once. We rely on this
fact later in eq_ref_table().
backporting of bug@30703 to 5.1.
The fixes are backed up with a regression test.
mysql-test/include/test_fieldsize.inc:
waiting to stop is to be actually exclusively for SQL thread.
mysql-test/suite/rpl/r/rpl_show_slave_running.result:
new results file is added.
mysql-test/suite/rpl/t/rpl_show_slave_running.test:
regression test for bug#30703 is added.
sql/mysqld.cc:
refining `show status like slave_running' handler to correspond to one of
`show slave status'.
sql/slave.cc:
A dbug-sync point is added to complement the regression test.
For temporary tables that are created with an engine that does
not provide the HTON_CAN_RECREATE, the truncate operation is
performed resorting to the optimized handler::ha_delete_all_rows
method. However, this means that the truncate will share
execution path, from mysql_delete, with truncate on regular
tables and other delete operations. As a consequence the truncate
operation, for the temporary table is logged, even if in row mode
because there is no distinction between this and the other delete
operations at binlogging time.
We fix this by checking if: (i) the binlog format, when the
truncate operation was issued, is ROW; (ii) if the operation is a
truncate; and (iii) if the table is a temporary table; before
writing to the binary log. If all three conditions are met, we
skip writing to the binlog. A side effect of this fix is that we
limit the scope of setting and resetting the
current_stmt_binlog_row_based. Now we just set and reset it
inside mysql_delete in the boundaries of the
handler::ha_write_row loop. This way we have access to
thd->current_stmt_binlog_row_based real value inside
mysql_delete.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Updated result for spurious truncate table.
mysql-test/suite/binlog/t/binlog_row_innodb_truncate.test:
Test case.
sql/sql_delete.cc:
Added check in mysql_delete before writing the TRUNCATE statement
to the binary log. Additionally, removed the set/reset of
current_stmt_binlog_row_based so that it happens just in the
boundaries of the handler::ha_write_row loop inside mysql_delete.
