mirror of
https://github.com/MariaDB/server.git
synced 2025-07-29 05:21:33 +03:00
Bug #17701, ALTER TABLE t1 ADD PARTITION for PARTITION BY LIST hangs test
- code wrongly tries to do a "fast alter partition", although not supported
This commit is contained in:
@ -130,6 +130,34 @@
|
||||
#define HA_ONLINE_DROP_UNIQUE_INDEX (1L << 9) /*drop uniq. online*/
|
||||
#define HA_ONLINE_ADD_PK_INDEX (1L << 10)/*add prim. online*/
|
||||
#define HA_ONLINE_DROP_PK_INDEX (1L << 11)/*drop prim. online*/
|
||||
/*
|
||||
HA_PARTITION_FUNCTION_SUPPORTED indicates that the function is
|
||||
supported at all.
|
||||
HA_FAST_CHANGE_PARTITION means that optimised variants of the changes
|
||||
exists but they are not necessarily done online.
|
||||
|
||||
HA_ONLINE_DOUBLE_WRITE means that the handler supports writing to both
|
||||
the new partition and to the old partitions when updating through the
|
||||
old partitioning schema while performing a change of the partitioning.
|
||||
This means that we can support updating of the table while performing
|
||||
the copy phase of the change. For no lock at all also a double write
|
||||
from new to old must exist and this is not required when this flag is
|
||||
set.
|
||||
This is actually removed even before it was introduced the first time.
|
||||
The new idea is that handlers will handle the lock level already in
|
||||
store_lock for ALTER TABLE partitions.
|
||||
|
||||
HA_PARTITION_ONE_PHASE is a flag that can be set by handlers that take
|
||||
care of changing the partitions online and in one phase. Thus all phases
|
||||
needed to handle the change are implemented inside the storage engine.
|
||||
The storage engine must also support auto-discovery since the frm file
|
||||
is changed as part of the change and this change must be controlled by
|
||||
the storage engine. A typical engine to support this is NDB (through
|
||||
WL #2498).
|
||||
*/
|
||||
#define HA_PARTITION_FUNCTION_SUPPORTED (1L << 12)
|
||||
#define HA_FAST_CHANGE_PARTITION (1L << 13)
|
||||
#define HA_PARTITION_ONE_PHASE (1L << 14)
|
||||
|
||||
/*
|
||||
Index scan will not return records in rowid order. Not guaranteed to be
|
||||
|
@ -4011,7 +4011,7 @@ uint prep_alter_part_table(THD *thd, TABLE *table, ALTER_INFO *alter_info,
|
||||
is freed by setting version to 0. table->s->version= 0 forces a
|
||||
flush of the table object in close_thread_tables().
|
||||
*/
|
||||
uint flags;
|
||||
uint flags= 0;
|
||||
table->s->version= 0L;
|
||||
if (alter_info->flags == ALTER_TABLE_REORG)
|
||||
{
|
||||
@ -4060,7 +4060,10 @@ uint prep_alter_part_table(THD *thd, TABLE *table, ALTER_INFO *alter_info,
|
||||
my_error(ER_PARTITION_FUNCTION_FAILURE, MYF(0));
|
||||
DBUG_RETURN(1);
|
||||
}
|
||||
*fast_alter_partition= flags ^ HA_PARTITION_FUNCTION_SUPPORTED;
|
||||
*fast_alter_partition=
|
||||
((flags & (HA_FAST_CHANGE_PARTITION | HA_PARTITION_ONE_PHASE)) != 0);
|
||||
DBUG_PRINT("info", ("*fast_alter_partition: %d flags: 0x%x",
|
||||
*fast_alter_partition, flags));
|
||||
if (alter_info->flags & ALTER_ADD_PARTITION)
|
||||
{
|
||||
/*
|
||||
@ -4660,7 +4663,6 @@ the generated partition syntax in a correct manner.
|
||||
DBUG_ASSERT(FALSE);
|
||||
}
|
||||
*partition_changed= TRUE;
|
||||
create_info->db_type= &partition_hton;
|
||||
thd->lex->part_info= tab_part_info;
|
||||
if (alter_info->flags == ALTER_ADD_PARTITION ||
|
||||
alter_info->flags == ALTER_REORGANIZE_PARTITION)
|
||||
|
@ -24,35 +24,6 @@
|
||||
#define HA_CAN_PARTITION_UNIQUE (1 << 2)
|
||||
#define HA_USE_AUTO_PARTITION (1 << 3)
|
||||
|
||||
/*
|
||||
HA_PARTITION_FUNCTION_SUPPORTED indicates that the function is
|
||||
supported at all.
|
||||
HA_FAST_CHANGE_PARTITION means that optimised variants of the changes
|
||||
exists but they are not necessarily done online.
|
||||
|
||||
HA_ONLINE_DOUBLE_WRITE means that the handler supports writing to both
|
||||
the new partition and to the old partitions when updating through the
|
||||
old partitioning schema while performing a change of the partitioning.
|
||||
This means that we can support updating of the table while performing
|
||||
the copy phase of the change. For no lock at all also a double write
|
||||
from new to old must exist and this is not required when this flag is
|
||||
set.
|
||||
This is actually removed even before it was introduced the first time.
|
||||
The new idea is that handlers will handle the lock level already in
|
||||
store_lock for ALTER TABLE partitions.
|
||||
|
||||
HA_PARTITION_ONE_PHASE is a flag that can be set by handlers that take
|
||||
care of changing the partitions online and in one phase. Thus all phases
|
||||
needed to handle the change are implemented inside the storage engine.
|
||||
The storage engine must also support auto-discovery since the frm file
|
||||
is changed as part of the change and this change must be controlled by
|
||||
the storage engine. A typical engine to support this is NDB (through
|
||||
WL #2498).
|
||||
*/
|
||||
#define HA_PARTITION_FUNCTION_SUPPORTED (1L << 12)
|
||||
#define HA_FAST_CHANGE_PARTITION (1L << 13)
|
||||
#define HA_PARTITION_ONE_PHASE (1L << 14)
|
||||
|
||||
/*typedef struct {
|
||||
ulonglong data_file_length;
|
||||
ulonglong max_data_file_length;
|
||||
|
Reference in New Issue
Block a user