MDEV-30984 Online ALTER table is denied with non-informative error messages
Group all the checks in online_alter_check_supported().
There is now two groups of checks:
1. A technical availability of online, that is checked before open_tables,
and affects table_list->lock_type. It's supposed to be safe to make it
TL_READ even if COPY algorithm will fall back to not-online, since MDL is
SHARED_UPGRADEABLE anyway.
2. An 'online' availability for a COPY algorithm. It can be done as late as
just before the copy_data_between_tables call. The lock_type influence is
disclosed above, so the only other place it affects is
Alter_info::supports_lock, where `online` flag is only used to decide
whether to report the error at the inplace preparation stage. We'd want to
make that at the last resort, which is COPY preparation, if no algorithm is
chosen by the user. So it's event better now.
Some changes are required to the autoinc support detection, as the check
now happens after mysql_prepare_alter_table:
* alter_info->drop_list is empty
* instead, dropped columns are in tmp_set
* alter_info->create_list now has every field that's in the new table.
* the column definition's change.str will be nonnull whether the column
remains in the new table (vs whether it was changed, as before).
But it also has `field` field set.
* IF EXISTS doesn't have to be dealt anymore
This infers that the changes are now checked in more detail: a field's
definition shouldn't be changed, vs a field shouldn't be mentioned in
the CHANGE list, as it was before. This is reflected by the line 193 test.
MDEV-30987 main.alter_table_online times out with view-protocol
disabie view-protocol for certain places:
1. While a transaction is in progress: a view gets locked for a
transaction duration, so DROP VIEW from a servicing conneciton
deadlocks. We can't just disable servicing connection, as
CREATE VIEW and DROP VIEW commit implicitly.
2. For querying Opened_table_definitions: the actual query executed
is `SELECT * FROM mysqltest_tmp_v`, then the view is dropped
Online alter and replication paths differ quite noticeably. It's time to
fix the mess. Online alter has to unpack the old table's data
(here conv_table), and then convert, while replication requires more
sophisticated track: handle possible conversions, treat extra replica
fields, and carefully deduce master's record length.
* Extract unpack_field.
* handle the unpacking progress through a state machine presented by
Unpack_record_state struct.
* Stick most of the online alter unpacking together under a single
conditional branch.
MDEV-30949 Direct leak in binlog_online_alter_end_trans
when committing a big transaction, online_alter_cache_log creates a cache
file. It wasn't properly closed, which was spotted by a memory leak from
my_register_filename. A temporary file also remained open.
Binlog wasn't affected by this, since it features its own file management.
A proper closing is calling close_cached_file. It deinits io_cache and
closes the underlying file. After closing, the file is expected to be
deleted automagically.