The problem is that QUICK_SELECT_DESC behaviour depends
on used_key_parts value which can be bigger than selected
best_key_parts value if an engine supports clustered key.
But used_key_parts is overwritten with best_key_parts
value that prevents from correct selection of index
access method. The fix is to preserve used_key_parts
value for further use in QUICK_SELECT_DESC.
mysql-test/r/innodb_mysql.result:
test case
mysql-test/t/innodb_mysql.test:
test case
sql/sql_select.cc:
preserve used_key_parts value for further use in QUICK_SELECT_DESC
Remove mysql_lock_have_duplicate(), since now we always
have TABLE_LIST objects for MyISAMMRG children
in lex->query_tables and keep it till the end of the
statement (sub-statement).
mysql-test/r/merge.result:
Update results (Bug#54811).
mysql-test/t/merge-big.test:
Update to new wait state.
mysql-test/t/merge.test:
Add a test case for Bug#54811.
sql/lock.cc:
Remove a function that is now unused.
sql/lock.h:
Remove a function that is now unused.
sql/sql_base.cc:
Don't try to search for duplicate table among THR_LOCK objects, TABLE_LIST list contains all used tables.
Merge and adjust a forgotten change to fix this bug.
rb://393 approved by Jimmy Yang
------------------------------------------------------------------------
r3794 | marko | 2009-01-07 14:14:53 +0000 (Wed, 07 Jan 2009) | 18 lines
branches/6.0: Allow the minimum length of a multi-byte character to be
up to 4 bytes. (Bug #35391)
dtype_t, dict_col_t: Replace mbminlen:2, mbmaxlen:3 with mbminmaxlen:5.
In this way, the 5 bits can hold two values of 0..4, and the storage size
of the fields will not cross the 64-bit boundary. Encode the values as
DATA_MBMAX * mbmaxlen + mbminlen. Define the auxiliary macros
DB_MBMINLEN(mbminmaxlen), DB_MBMAXLEN(mbminmaxlen), and
DB_MINMAXLEN(mbminlen, mbmaxlen).
Try to trim and pad UTF-16 and UTF-32 with spaces as appropriate.
Alexander Barkov suggested the use of cs->cset->fill(cs, buff, len, 0x20).
ha_innobase::store_key_val_for_row() now does that, but the added function
row_mysql_pad_col() does not, because it doesn't have the MySQL TABLE object.
rb://49 approved by Heikki Tuuri
------------------------------------------------------------------------
switching binlog format to ROW
BUG 52616 fixed the case which the user would switch from STMT to
ROW binlog format, but the server would silently ignore it. After
that fix thd->is_current_stmt_binlog_format_row() reports correct
value at logging time and events are logged in ROW (as expected)
instead of STMT as they were previously and wrongly logged.
However, the fix was only partially complete, because on
disconnect, at THD cleanup, the implicit logging of temporary
tables is conditionally performed. If the binlog_format==ROW and
thd->is_current_stmt_binlog_format_row() is true then DROPs are
not logged. Given that the user can switch from STMT to ROW, this
is wrong because the server cannot tell, just by relying on the
ROW binlog format, that the tables have been dropped before. This
is effectively similar to the MIXED scenario when a switch from
STMT to ROW is triggered.
We fix this by removing this condition from
close_temporary_tables.
mysql-test/extra/binlog_tests/drop_temp_table.test:
Added binlog test case.
mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result:
Result changes because:
- there is a missing drop on three temporary tables
- it now contains results for the test added
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Result now contains the implicit drop for the temporary table.
mysql-test/suite/binlog/r/binlog_stm_drop_tmp_tbl.result:
Result file changed because it now contains results for added
test case.
mysql-test/suite/rpl/r/rpl_drop_temp.result:
Result file changed because it now contains results for added
test case.
mysql-test/suite/rpl/t/rpl_drop_temp.test:
Added replication test case.
sql/sql_base.cc:
Removed the condition that would make the server to skip
logging implicit drops when ROW binary log format mode was
in use.
Additionally, deployed DBUG_ENTER/RETURN macros.
This bug is a consequence of WL#5349, as the
default storage engine was changed.
The fix was to explicitly add an ENGINE
clause to a CREATE TABLE statement, to
ensure that we test case preservement on
MyISAM.
DROP USER
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave
executes the log event, 'CURRENT_USER()' is expand to the user of slave
SQL thread, but SQL thread's user name always NULL. This breaks the replication.
After this patch, session's user will be written into query log events
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
mysql-test/include/diff_tables.inc:
Expend its abilities.
Now it can diff not only in sessions of 'master' and 'slave', but
other sessions as well.
mysql-test/include/rpl_diff_tables.inc:
Diff the same table between master and slaves.
sql/log_event.cc:
session's user will be written into Query_log_event, if is_current_user_used() is TRUE.
On slave SQL thread, Only thd->variables.current_user is written into Query_log_event,
if it exists.
sql/sql_acl.cc:
On slave SQL thread, grantor should copy from thd->variables.current_user, if it exists
sql/sql_class.h:
On slave SQL thread, thd->variables.current_user is used to store the applying event's
invoker.
The problem was that if a query accessing a view was blocked due to
conflicting locks on tables in the view definition, it would be possible
for a different connection to alter the view definition before the view
query completed. When the view query later resumed, it used the old view
definition. This meant that if the view query was later repeated inside
the same transaction, the two executions of the query would give different
results, thus breaking repeatable read. (The first query used the old
view definition, the second used the new view definition).
This bug is no longer repeatable with the recent changes to the metadata
locking subsystem (revno: 3040). The view query will no longer back-off
and release the lock on the view definiton. Instead it will wait for
the conflicting lock(s) to go away while keeping the view definition lock.
This means that it is no longer possible for a concurrent connection to
alter the view definition. Instead, any such attempt will be blocked.
In the case from the bug report where the same view query was executed
twice inside the same transaction, any ALTER VIEW from other connections
will now be blocked until the transaction has completed (or aborted).
The view queries will therefore use the same view definition and we will
have repeatable read.
Test case added to innodb_mysql_lock.test.
This patch contains no code changes.
This deadlock happened if DROP DATABASE was blocked due to an open
HANDLER table from a different connection. While DROP DATABASE
is blocked, it holds the LOCK_mysql_create_db mutex. This results
in a deadlock if the connection with the open HANDLER table tries
to execute a CREATE/ALTER/DROP DATABASE statement as they all
try to acquire LOCK_mysql_create_db.
This patch makes this deadlock scenario very unlikely by closing and
marking for re-open all HANDLER tables for which there are pending
conflicing locks, before LOCK_mysql_create_db is acquired.
However, there is still a very slight possibility that a connection
could access one of these HANDLER tables between closing/marking for
re-open and the acquisition of LOCK_mysql_create_db.
This patch is for 5.1 only, a separate and complete fix will be
made for 5.5+.
Test case added to schema.test.
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
The server crashed on an attempt to optimize a MERGE table with
non-existent child table.
mysql_admin_table() relied on the table to be successfully open
if a table object had been allocated.
Changed code to check return value of the open function before
calling a handler:: function on it.
mysql-test/r/merge.result:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Updated result file.
mysql-test/t/merge.test:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Changed tests to respect changed TEMPORARY MERGE locking (unrelated).
Changed tests to respect changed CREATE TABLE ... LIKE (unrelated).
Changed tests to respect that no new tables can be created
under LOCK TABLE (unrelated).
Added test for Bug#47633.
Changed error numbers to symbolic names.
Added test for child locking for ALTER under LOCK TABLE.
Since Bug 36171 is not pushed yet, not the whole patch has been backported.
mysys/my_delete.c:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Fixed error reporting.
Fixed indentation.
mysys/my_mmap.c:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Added DBUG.
sql/item_func.cc:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Added Debug Sync point, required by merge_sync.test.
sql/sql_table.cc:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Do not call handler:: functions if the table was not opened
successfully.
Added Debug Sync point, required by merge_sync.test.
storage/myisam/mi_check.c:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE
Unmap memory before exchanging data files. Needed on Windows.
storage/myisammrg/ha_myisammrg.cc:
Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111
Added Debug Sync point, required by merge_sync.test.
merge_sync.test will be introduced by a patch for Bug 36171,
which is not pushed yet.
returns nothing
When looking for table or database names inside INFORMATION_SCHEMA
we must convert the table and database names to lowercase (just as it's
done in the rest of the server) when lowercase_table_names is non-zero.
This will allow us to find the same tables that we would find if there
is no condition.
Fixed by converting to lower case when extracting the database and
table name conditions.
Test case added.
During creation of the table list of
processed tables hidden I_S table 'VARIABLES'
is erroneously added into the table list.
it leads to ER_UNKNOWN_TABLE error in
TABLE_LIST::add_table_to_list() function.
The fix is to skip addition of hidden I_S
tables into the table list.
mysql-test/r/information_schema.result:
test case
mysql-test/t/information_schema.test:
test case
sql/sql_show.cc:
The fix is to skip addition of hidden I_S
tables into the table list.
DML flow and SAVEPOINT
The problem was that replication could break if a transaction involving
both transactional and non-transactional tables was rolled back to a
savepoint. It broke if a concurrent connection tried to drop a
transactional table which was locked after the savepoint was set.
This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the
lock on the table was dropped by the transaction. When the slave later
tried to apply the binlog, it would fail as the table would already
have been dropped.
The reason for the problem is that transactions involving both
transactional and non-transactional tables are written fully to the
binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks
acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT.
This allowed a second connection to drop a table only used between
SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog
to refer to a non-existing table when it was written during ROLLBACK
TO SAVEPOINT.
This patch fixes the problem by not releasing metadata locks when
ROLLBACK TO SAVEPOINT is executed if binlogging is enabled.
The assert was triggered if a connection executing TRUNCATE
on a InnoDB table was killed during open_tables.
This bug was fixed in the scope of Bug #45643
"InnoDB does not support replication of TRUNCATE TABLE".
This patch adds test coverage to innodb_mysql_sync.test.
require O(#scans) memory
When an index merge operation was restarted, it would
re-allocate the Unique object controlling the duplicate row
ID elimination. Fixed by making the Unique object a member
of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout
the lifetime of this object.
------------------------------------------------------------
revno: 3523
revision-id: marko.makela@oracle.com-20100624104620-pklunowaigv7quu9
parent: jimmy.yang@oracle.com-20100624021010-oh2hnp8e1xbaax6u
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: 5.1-innodb
timestamp: Thu 2010-06-24 13:46:20 +0300
message:
Bug#54679: alter table causes compressed row_format to revert to compact
ha_innobase::create(): Add the local variable row_type = form->s->row_type.
Adjust it to ROW_TYPE_COMPRESSED when ROW_FORMAT is not specified or inherited
but KEY_BLOCK_SIZE is. Observe the inherited ROW_FORMAT even when it is not
explicitly specified.
innodb_bug54679.test: New test, to test the bug and to ensure that there are
no regressions. (The only difference in the test result without the patch
applied is that the first ALTER TABLE changes ROW_FORMAT to Compact.)
ha_innobase::create(): Add the local variable row_type = form->s->row_type.
Adjust it to ROW_TYPE_COMPRESSED when ROW_FORMAT is not specified or inherited
but KEY_BLOCK_SIZE is. Observe the inherited ROW_FORMAT even when it is not
explicitly specified.
innodb_bug54679.test: New test, to test the bug and to ensure that there are
no regressions. (The only difference in the test result without the patch
applied is that the first ALTER TABLE changes ROW_FORMAT to Compact.)
file .\filesort.cc, line 149 (part II)
Problem: the server didn't disregard sort order
for some zero length tuples.
Fix: skip sort order in such a case
(zero length NOT NULL string functions).
mysql-test/r/select.result:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test result.
mysql-test/t/select.test:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- test case.
sql/sql_select.cc:
Fix for bug #54459: Assertion failed: param.sort_length,
file .\filesort.cc, line 149 (part II)
- disregard sort order for zero length NOT NULL string functions
along with zero length NOT NULL fields.
------------------------------------------------------------
revno: 3672
committer: lars-erik.bjork@sun.com
branch nick: 48067-mysql-6.0-codebase-bugfixing
timestamp: Mon 2009-10-26 13:51:43 +0100
message:
This is a patch for bug#48067
"A temp table with the same name as an existing table, makes drop
database fail"
When dropping the database, mysql_rm_known_files() reads the contents
of the database directory, and creates a TABLE_LIST object, for each
.frm file encountered. Temporary tables, however, are not associated
with any .frm file.
The list of tables to drop are passed to mysql_rm_table_part2().
This method prefers temporary tables over regular tables, so if
there is a temporary table with the same name as a regular, the
temporary is removed, leaving the regular table intact.
Regular tables are only deleted if there are no temporary tables
with the same name.
This fix ensures, that for all TABLE_LIST objects that are created
by mysql_rm_known_files(), 'open_type' is set to 'OT_BASE_ONLY', to
indicate that this is a regular table. In all cases in
mysql_rm_table_part2() where we prefer a temporary table to a
non-temporary table, we chek if 'open_type' equals 'OT_BASE_ONLY'.
mysql-test/r/temp_table.result:
The expected result of the test.
mysql-test/t/temp_table.test:
Test based on the bug report.
sql/sql_db.cc:
For all TABLE_LIST objects that are created by mysql_rm_known_files(),
'open_type' is set to 'OT_BASE_ONLY', to indicate that these are
regular tables.
sql/sql_table.cc:
Check if 'open_type' is set to 'OT_BASE_ONLY, every place a temporary table is
preferred to a non-temporary table.
