diff options
author | Marko Mäkelä <marko.makela@mariadb.com> | 2020-10-22 13:19:18 +0300 |
---|---|---|
committer | Marko Mäkelä <marko.makela@mariadb.com> | 2020-10-22 13:19:18 +0300 |
commit | 1619ae899099c4934f3b5919b2398c95a7cacc94 (patch) | |
tree | 1f97834427618091e91a99907c0d08a9fb19b19c /sql/ha_partition.cc | |
parent | 77c00799e501def2868399ec3f39ee1bee3f2384 (diff) | |
download | mariadb-git-1619ae899099c4934f3b5919b2398c95a7cacc94.tar.gz |
MDEV-23672: Partly revert an incorrect fix
In commit 7eda55619654b76add275695e0a6039e60876e81 we removed a
valid debug assertion.
AddressSanitizer would trip when writing undo log for an INSERT
operation that follows the problematic ALTER TABLE because the
v_indexes would refer to an index object that was freed during
the execution of ALTER TABLE.
The operation to remove NOT NULL attribute from a column should
lead into any affected indexes to be dropped and re-created.
But, the SQL layer set the ha_alter_info->handler_flags to
HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE|ALTER_COLUMN_NULLABLE
(that is, InnoDB was asked to add an index and change the column,
but not to drop the index that depended on the column).
Let us restore the debug assertion that catches this problem
outside AddressSanitizer, and 'defuse' the offending ALTER TABLE
statement in the test until something has been fixed in the SQL layer.
Diffstat (limited to 'sql/ha_partition.cc')
0 files changed, 0 insertions, 0 deletions