MDEV-33524: marked_for_read assertion with virtual column

[DaveGosselin-MariaDB]

There are two commits in this PR. The first commit fixes a lockup when running the vcol suite with --view-protocol. The second commit fixes the problem from the named ticket.

Test lockup:

MDEV-33524:  marked_for_read assertion with virtual column

vcol.vcol_misc deadlocks under --view-protocol at the
FLUSH TABLES WITH READ LOCK block.  The main connection holds
the global read lock.  The SELECT COUNT(*) FROM t1 query becomes
CREATE OR REPLACE VIEW on a separate connection, and that DDL
blocks on the read lock and never returns.  So the same mysqltest
client never reaches unlock tables.  The fix is to wrap only that
one SELECT in the view_protocol guards.

Actual fix:

MDEV-33524:  marked_for_read assertion with virtual column

A couple of things interact in this scenario.

1. A virtual column whose value depends on session state, such as a
VCOL calling DATE_FORMAT, has fix_fields (via fix_expr) run on it
again before each INSERT.  For a table reused from the cache this runs in
Vcol_expr_context before setup_tables sets the table map.  The test
first opens t1 with a SELECT that fails before setup_tables, leaving
it cached with map zero.

2. When the connection character set needs conversion, CONCAT (more
generally, any charset aggregation) wraps that column in a charset
converter.  The converter evaluates any argument reported as
constant, so it calls val_str() on the column as part of
fix_fields, before a row exists and without the column in the read
set.  On DEBUG builds this fails the marked_for_read assertion;
otherwise it reads an unread column.

Consequently:
When a table instance is opened, fix_fields runs with table->map
already nonzero, but the fix_fields (via fix_expr) call from vcol_fix_expr
did not have it nonzero; so set table->map=1 during Vcol_expr_context::init.
The original Vcol_expr_context::init() (MDEV-24176) called
init_lex_with_single_table, which set table->map= 1 as a side effect.
A later merge of 10.2 into 10.3 (6f6c74b0d18) replaced that call with
a backup of table->expr_arena, dropping the side effect.
The destructor of the Vcol_expr_context will reset the map back to its
original value.

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.