parameters don't match
Revert the changes of the default values of innodb_file_per_table
and innobase_file_format in 5.5, until WL#5135 is implemented.
REBUILD PARTITION under LOCK TABLE
Collapsed patch including updates from the reviews.
In case of failure in ALTER ... PARTITION under LOCK TABLE
the server could crash, due to it had modified the locked
table object, which was not reverted in case of failure,
resulting in a bad table definition used after the failed
command.
Solved by instead of altering the locked table object and
its partition_info struct, creating an internal temporary
intermediate table object used for altering,
just like the non partitioned mysql_alter_table.
So if an error occur before the alter operation is complete,
the original table is not modified at all.
But if the alter operation have succeeded so far that it
must be completed as whole,
the table is properly closed and reopened.
(The completion on failure is done by the ddl_log.)
mysql-test/suite/parts/inc/partition_fail.inc:
Added tests under LOCK TABLE
mysql-test/suite/parts/r/partition_debug_innodb.result:
Updated results
mysql-test/suite/parts/r/partition_debug_myisam.result:
Updated results
mysql-test/suite/parts/r/partition_special_innodb.result:
updated result
mysql-test/suite/parts/t/partition_special_innodb.test:
changing comment, since this patch also fixes this.
sql/sql_partition.cc:
Added TODO, to use DBUG_SUICIDE() instead of abort()
to avoid core-files on expected crashes.
Removed unused arguments to fast_end_partition.
Opening a intermediate table in prep_alter_part_table, instead of altering
(a possible locked) normally opened table.
That way we do not have to do anything more than close
the intermediate table on error,
leaving the ordinary table opened and locked.
Also making sure that the intermediate table are
closed/destroyed on failure. If no error occur
it is later destroyed in the end of fast_alter_partition_table.
Added ha_external_lock to make sure MyISAM flushed the index file
after copying the partitions.
This also leads to removal of the special close and removal from
the table cache for other instances of the table.
sql/sql_partition.h:
Changed the arguments for prep_alter_part_table and
fast_alter_partition_table to use an intermediate table
instead of altering a (possibly locked) normal table.
sql/sql_table.cc:
Using an intermediate table created in prep_alter_part_table
to be used in fast_alter_partition_table, also closing/destroying
it on failure.
argument of inline_mysql_mutex_init in sql_base.cc.
When initializing LOCK_dd_owns_lock_open mutex pass
correct PSI key instead of NULL value.
mysql-test/suite/perfschema/r/dml_setup_instruments.result:
Updated test results after adding P_S instrumentation
for LOCK_dd_owns_lock_open.
sql/sql_base.cc:
When initializing LOCK_dd_owns_lock_open mutex pass
correct PSI key instead of NULL value.
reports corruption along with timeout
This patch updates the result file for the
parts.partition_special_innodb test case which was, by mistake,
not updated in the original patch.
Before this fix, the test output for perfschema.server_init would
vary between executions, because some of the objects tested were
not guaranteed to exist in all configurations / code paths.
This fix removes these weak tests.
Also, comments referring to abandonned code have been cleaned up.
adding new indexes
A fast alter table requires that the existing (old) table
and indices are unchanged (i.e only new indices can be
added). To verify this, the layout and flags of the old
table/indices are compared for equality with the new.
The PACK_KEYS option is a no-op in InnoDB, but the flag
exists, and is used in the table compare. We need to
check this (table) option flag before deciding whether an
index should be packed or not. If the table has
explicitly set PACK_KEYS to 0, the created indices should
not be marked as packed/packable.
Before this fix, the server could crash inside a memcpy when reading data
from the EVENTS_WAITS_CURRENT / HISTORY / HISTORY_LONG tables.
The root cause is that the length used in a memcpy could be corrupted,
when another thread writes data in the wait record being read.
Reading unsafe data is ok, per design choice, and the code does sanitize
the data in general, but did not sanitize the length given to memcpy.
The fix is to also sanitize the schema name / object name / file name
length when extracting the data to produce a row.
Bug#56657: Test still uses "--exec rm -f ..." which is non-portable
Bug#56601: Test uses Unix path for temporary file, fails, and writes misleading message
Several tests that was written in a non portable way (failed on windows)
Fixed by
1) backporting the fix for replace_result to also apply to list_files
(mysqltest from mysql-trunk)
2) replacing all #p#/#sp#/#tmp# to #P#/#SP#/#TMP#/
(innodb always converts filenames to lower case in windows).
3) replacing '--exec rm -f' with '--remove_files_wildcard'
4) replacing a perl snippet with '--write_file'
client/mysqltest.cc:
backport from mysql-trunk to allow replace_result to apply
also on list_files
mysql-test/suite/parts/inc/partition_check_drop.inc:
Compensate for differences between innodb on windows vs unix.
Using mysqltest command, instead of unix command to remove files.
mysql-test/suite/parts/inc/partition_crash.inc:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/inc/partition_fail.inc:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/inc/partition_layout.inc:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/inc/partition_layout_check1.inc:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/inc/partition_layout_check2.inc:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/r/partition_recover_myisam.result:
updated result
mysql-test/suite/parts/r/partition_special_myisam.result:
updated result
mysql-test/suite/parts/t/part_supported_sql_func_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter1_1_2_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter1_2_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter2_1_1_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter2_1_2_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter2_2_2_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_alter4_innodb.test:
Test takes very long time, require --big flag
mysql-test/suite/parts/t/partition_debug_sync_innodb.test:
compensate for differences between innodb on windows vs unix
mysql-test/suite/parts/t/partition_recover_myisam.test:
more generic suppression (failed in windows)
mysql-test/suite/parts/t/partition_special_myisam.test:
Using portable mysqltest command 'write_file' instead of perl snippet.
Implemented post review comments.
Added --force to the mysql_upgrade command in the test scripts,
so that the test output does not depends on whether other tests involving an
upgrade have been executed or not in the same test suite execution.
With recent changes in the performance schema default sizing parameters,
the memory used by a mysqld binary increased accordingly.
This negatively affects the MTR test suite,
because running several tests in parallel now consumes more ressources.
The fix is to leave the default production values unchanged,
and to configure the MTR environment to limit memory
used when running tests in the test suite, which is ok
because only a few objects are typically used within a test script.
This fix:
- changed the default configuration in MTR to use less memory
- adjusted the performance schema tests accordingly
Note that 1,000 mutex instances was too short and caused test failures
in the past in team trees, so the default used is now 10,000 in MTR.
The amount of memory used by the performance schema itself
can be observed with the statement SHOW ENGINE PERFORMANCE_SCHEMA STATUS
On Solaris with version 3.4.6, the ha_example.so shared library is built
with DTrace and the server is built without DTrace support. This occurs
because dtrace.cmake disables DTrace support for 3.4.6, but still set
HAVE_DTRACE, which causes probes_mysql.h to include probes_mysql_dtrace.h
instead of probes_mysql_nodtrace.h.
This patch fixes this by not setting HAVE_DTRACE on Solaris for GCC 3.4.6.
case than in corr index".
Server was unable to find existing or explicitly created supporting
index for foreign key if corresponding statement clause used field
names in case different than one used in key specification and created
yet another supporting index.
In cases when name of constraint (and thus name of generated index)
was the same as name of existing/explicitly created index this led
to duplicate key name error.
The problem was that unlike all other code Key_part_spec::operator==()
compared field names in case sensitive fashion. As result routines
responsible for getting rid of redundant generated supporting indexes
for foreign key were not working properly for versions of field names
using different cases.
(backported from mysql-trunk)
sql/sql_class.cc:
Make field name comparison case-insensitive like it is
in the rest of server.
The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for
INSERT DELAYED when inserting multi values in one statement.
It's safe. But it causes an unsafe warning in SBR.
Make INSERT DELAYED safe by logging it as INSERT without DELAYED.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
Updated the test file to test multi INSERT DELAYED statement
is no longer causes an unsafe warning and binlogged as INSERT
without DELAYED.
mysql-test/extra/rpl_tests/create_recursive_construct.inc:
Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_statement_insert_delayed.result:
Test result for BUG#54579.
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Updated for the patch of bug#54579.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Updated for the patch of bug#54579.
sql/sql_insert.cc:
Added code to genetate a new query string for removing
DELAYED keyword for multi INSERT DEALAYED statement.
sql/sql_yacc.yy:
Added code to record the DELAYED keyword position and remove the setting
of unsafe statement for INSERT DELAYED statement
