MDEV-24511 null field is created with CREATE..SELECT
The regression has been initially appeared by MDEV-12588 patch (441349aa).
The reason CREATE... SELECT NULL does not create null field is that
it calls handle_select(), where the field is created directly from Item,
by calling type_handler->type_handler_for_tmp_table(), instead of plain
type_handler.
In UNION case, we'll already have Item_field's containing UNION'ed tmp
table fields to the moment of select_create::prepare() call.
There, item's type_handler is used directly in
st_select_lex_unit::join_union_item_types(), instead of
type_handler_for_tmp_table() or type_handler_for_union().
Using those two involve too many changes in CREATE...SELECT...UNION
behavior, which may be reasonably undesired to be pushed in 10.3
However, patching Field_null::type_handler() directly seems to be accurate
enough.
MDEV-26205 Merge new release of InnoDB 5.7.35 to 10.2
236f825...
by
Sachin Agarwal <email address hidden>
Bug #31576731 INNODB_FT_TOTAL_CACHE_SIZE NOT CAPPED WHEN SET TO 32000000
Problem:
Server throws OOM error when we execute twitter load with SELECTs
for UPDATE + UPDATES, and SELECT queries on tables with full-text
index.
FTS cache->total_memory store count of total memory allocated to FTS
cache (for all fulltext indexes on a table).
For each word in fts cache, we store doc-id & word position in a
node->ilist.
we increment cache->total_memory with size of doc-id & word position
whereas we allocate ilist in chuck of 16, 32 ,64 bytes or 1.2 times
of last size.
When we wil insert huge amount of data into the FTS aux index tables
then collectively these small chucks for each token become huge
unaccounted memory allocated for FTS cache.
Fix:
Incremented cache->total_memory by size of chunk allocated to
node->ilist.
RB: 25286
Reviewed by : Rahul Agarkar <email address hidden>
MDEV-26203 CREATE INDEX may enforce incorrect maximum column length
ha_innobase::prepare_inplace_alter_table(): Unless the table is
being rebuilt, determine the maximum column length based on the
current ROW_FORMAT of the table. When TABLE_SHARE (and the .frm file)
contains no explicit ROW_FORMAT, InnoDB table creation or rebuild
will use innodb_default_row_format.
Based on mysql/mysql-server@3287d33acdc4260806a2a407ca15e9d1e04dddcb
