You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WL#16268: Support for InnoDB Partitions Phase 2 -- Postfix [noclose]
Bug#36679859 revealed some flaws in the algorithm that updates the
partition metadata both in DD and in GS.
Issue: The algorithm that marks the per partition secondary_load flag
in DD based on CREATE_INFO faces the following problems:
i) A partition inherits its secondary_load value from the corresponding
partition in CREATE_INFO based on its name. However, in case
repartitioning has happened, the name does not guarantee any logical
mapping between the new and the old partition (e.g., HASH partitioning)
ii) New partitions that occur either from ADD PARTITION or
repartitioning are marked with secondary_load = 0. In case the DDL
triggers a full table reload, these partitions stay with the flag equal
to zero leading to an inconsistency: the partitions are loaded but
DD has the impression that they are not
Fix: We change the corresponding algorithm in dd_table.cc to the
following:
If there is not an existing partitioning on the table:
All partitions that are produced by this DDL will have a
secondary_load flag with value equal to the table's secondary_load
value
Else:
If (i) the partitioning type has changed OR
(ii) it is HASH partitioning OR
(iii) the partitioning attributes have changed:
If there exists at least one partition loaded:
Mark all partitions with secondary_load=1 (Full reload)
Else:
Mark all partitions with secondary_load=0
Else:
// In this case, we have RANGE partitioning where type/attrs have
// not changed, hence we can use the existing algorithm
Similarly, we also modify the algorithm for subpartitions.
Other changes:
- Use the std::ranges API in the algorithm
- Re-record tests that have broken on PB2
Change-Id: I550e40c12dc67b6cb6dc1c1e1246b9f7f2a0c522
0 commit comments