Fix the regression introduced in
dfb41fddf6.
In the restructure of mysql_rm_table_no_locks the early condition
of !frm_error that enabled non_tmp_table_deleted, and hence the
query cache invalidation, was removed.
The query_cache_invalidate1(thd, dbnorm) called after
mysql_rm_table_no_locks depends on the query cache removal
(for unexamined reasons).
Under DROP DATABASE, in mysql_rm_table_no_locks, dont_log_query
is true preventing the late setting of non_tmp_table_deleted
(which retained one of its purposes as a replication deletion
of temporary tables, but not query cache invalidation).
The non_temp_tables_count however can still be used to invalidate
the query cache.
For commands
(1) alter table t1 add partition (partition p2);
(2) alter table t1 add partition (partition px history);
It printed the same error message:
Wrong partitioning type, expected type: `SYSTEM_TIME`
For (1) it is not clear from the syntax that we are trying to add
HASH partition. For (2) it is not clear that the table partitioning is
different than SYSTEM_TIME. Now it prints what type we are trying to
add to what type of partitioning.
Fixed warning unused function rename_field_in_list() for compilation
without partitioning.
Specifically:
Revert "MDEV-29664 Assertion `!n_mysql_tables_in_use' failed in innobase_close_connection"
This reverts commit ba875e9396.
Revert "MDEV-29620 Assertion `next_insert_id == 0' failed in handler::ha_external_lock"
This reverts commit aa08a7442a.
Revert "MDEV-29628 Memory leak after CREATE OR REPLACE with foreign key"
This reverts commit c579d66ba6.
Revert "MDEV-29609 create_not_windows test fails with different result"
This reverts commit cb583b2f1b.
Revert "MDEV-29544 SIGSEGV in HA_CREATE_INFO::finalize_locked_tables"
This reverts commit dcd66c3814.
Revert "MDEV-28933 CREATE OR REPLACE fails to recreate same constraint name"
This reverts commit cf6c517632.
Revert "MDEV-28933 Moved RENAME_CONSTRAINT_IDS to include/sql_funcs.h"
This reverts commit f1e1c1335b.
Revert "MDEV-28956 Locking is broken if CREATE OR REPLACE fails under LOCK TABLES"
This reverts commit a228ec80e3.
Revert "MDEV-25292 gcol.gcol_bugfixes --ps fix"
This reverts commit 24fff8267d.
Revert "MDEV-25292 Disable atomic replace for slave-generated or-replace"
This reverts commit 2af15914cb.
Revert "MDEV-25292 backup_log improved"
This reverts commit 34398a20b5.
Revert "MDEV-25292 Atomic CREATE OR REPLACE TABLE"
This reverts commit 93c8252f02.
Revert "MDEV-25292 Table_name class for (db, table_name, alias)"
This reverts commit d145dda9c7.
Revert "MDEV-25292 ha_table_exists() cleanup and improvement"
This reverts commit 409b8a86de.
Revert "MDEV-25292 Cleanups"
This reverts commit 595dad83ad.
Revert "MDEV-25292 Refactoring: moved select_field_count into Alter_info."
This reverts commit f02af1d229.
The ALTER related code cannot do at the same time both:
- modify partitions
- change column data types
Explicit changing of a column data type together with a partition change is
prohibited by the parter, so this is not allowed and returns a syntax error:
ALTER TABLE t MODIFY ts BIGINT, DROP PARTITION p1;
This fix additionally disables implicit data type upgrade
(e.g. from "MariaDB 5.3 TIME" to "MySQL 5.6 TIME", or the other way
around according to the current mysql56_temporal_format) in case of
an ALTER modifying partitions, e.g.:
ALTER TABLE t DROP PARTITION p1;
In such commands now only the partition change happens, while
the data types stay unchanged.
One can additionally run:
ALTER TABLE t FORCE;
either before or after the ALTER modifying partitions to
upgrade data types according to mysql56_temporal_format.
10.5 part: test cases and comments.
The code is in the merge commit 74fe1c44aa
When f.ex. table is partitioned by HASH(a) and we rename column `a' to
`b' partitioning filter stays unchanged: HASH(a). That's the wrong
behavior.
The patch updates partitioning filter in accordance to the new columns
names. That includes partition/subpartition expression and
partition/subpartition field list.
When f.ex. table is partitioned by HASH(a) and we rename column `a' to
`b' partitioning filter stays unchanged: HASH(a). That's the wrong
behavior.
The patch updates partitioning filter in accordance to the new columns
names. That includes partition/subpartition expression and
partition/subpartition field list.
make_tmp_name() creates temporary name with prefix containing PID and
TID. This prefix influences max length of the rest of the name (the
whole name is limited by NAME_LEN). During the test run PID and TID
can change. PID increases when the server restarts. TID is incremented
with the new connections (generated by next_thread_id(), is not the
posix thread ID).
During the test run PID can increase max 2 decimal positions: from
tens to thousands this requires ~900 restarts. TID depends on
connection count, but for test we assume it will not trespass 100000
connections which is 5 decimal positions. So it should be enough to
reserve 7 characters for PID and TID increment.
The patch reserves more: it reserves 12 characters for 7-decimal PID
and 5-decimal TID plus 4 chars of additional reserve (for future
prefix changes) and assumes minimal legth of the prefix is 30 bytes:
#sql-backup-PID-TID-
#sql-create-PID-TID-
4-6-PID-TID- is 10 + 4 + PID + TID, so PID + TID is 16 chars (7 + 5 + 4).
Usually when we get into finalize_locked_tables() with error
m_locked_tables_count was not decremented. m_locked_tables_count is
decremented when we drop the original table and if we failed that
m_locked_tables_count is expected intact.
The bug comes from the fact that finalize_atomic_replace() violates
the above contract. It does HA_EXTRA_PREPARE_FOR_DROP and decrements
m_locked_tables_count. Then it tries rename_table_and_triggers() and
fails. With decremented m_locked_tables_count reopen_tables() does
nothing and we don't get new value for pos_in_locked_tables->table.
The test case demonstrates ER_ERROR_ON_RENAME where non-atomic CREATE
OR REPLACE would not fail. The original RENAME TABLE fails under such
broken environment, so nothing is wrong with atomic CREATE OR REPLACE
failing there too.
