CMake Warning (dev) at cmake/plugin.cmake:288 (GET_TARGET_PROPERTY):
Policy CMP0045 is not set: Error on non-existent target...
Also, fix condition argument in ADD_FEATURE_INFO. It is not a string
but boolean
CMake Warning (dev) at cmake/plugin.cmake:288 (GET_TARGET_PROPERTY):
Policy CMP0045 is not set: Error on non-existent target...
Also, fix condition argument in ADD_FEATURE_INFO. It is not a string
but boolean
ha_partition stores records in array of m_ordered_rec_buffer and uses
it for prio queue in ordered index scan. When the records are restored
from the array the blob buffers may be already freed or rewritten.
The solution is to take temporary ownership of cached blob buffers via
String::swap(). When the record is restored from m_ordered_rec_buffer
the ownership is returned to table fields.
Cleanups:
init_record_priority_queue(): removed needless !m_ordered_rec_buffer
check as there is same assertion few lines before.
dbug_print_row() for arbitrary row pointer
JSON_REPLACE() function executed with an error on Spider SE.
This patch fixes the problem, and it also fixes the MDEV-24541.
The problem is that Item_func_json_insert::func_name() returns
the wrong function name "json_update".
The Spider SE reconstructs a query based on the return value
in some cases. Thus, if the return value is wrong, the Spider SE
may generate a wrong query.
1. rename option DEPENDENCIES in MYSQL_ADD_PLUGIN() to DEPENDS
to be consistent with other cmake commands and macros
2. use this DEPENDS option in plugins
3. add dependencies to the plugin embedded target too
4. plugins don't need to add GenError dependency explicitly,
all plugins depend on it automatically
Server crashes in Field::register_field_in_read_map upon select from
partitioned table with indexed by prefix virtual column.
After several read-mark fixes a problem has surfaced:
Since KEY (c(10),a) uses only a prefix of c, a new field is created,
duplicated from table->field[3], with a new length. However,
vcol_inco->expr is not copied.
Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL
in ha_partition::index_init().
Solution: copy vcol_info from table field when it's set up.
according to MDEV-17550 it's informational, not fatal.
"last committed" is part of the certification index purge process.
depending on what tests and in what order are run it can be triggered
at unspecified times during the testing. If the test is happen to
shut down the server at this very time, the log will have:
[Warning] WSREP: Failed to report last committed XXXYYYZZZ, -77 (File descriptor in bad state)
fix main.processlist_notembedded test
* before EXPLAINing `select sleep` wait for select to start
(fixes "Target is not running an EXPLAINable command")
* after killing sleep, wait for it to die
(fixes test failures on --repeat when old sleep shows on a test rerun)
* unify with 10.3, copy minor changes from there
(`--echo End of 5.5` vs `--echo # End of 5.5`, etc)
ha_innobase::can_switch_engines(): Use DBUG_RETURN instead of return
to match the DBUG_ENTER. This fixes a bootstrap failure of debug builds
using the default setting -DWITH_DBUG_TRACE=ON.
In commit 2647fd101d (MDEV-19445)
we fixed a race condition around the INFORMATION_SCHEMA tables
that access the table identified by the global variable
innodb_ft_aux_table. Thanks to MDEV-16678 we could fix it
even better by using MDL instead of the InnoDB dict_sys latches.
Before entering DML or DDL execution in the storage engine, the SQL layer
will have acquired metadata lock (MDL) on the current table name as well
as the names of FOREIGN KEY (grand)child tables (that is,
tables whose REFERENCES clauses point to the current table).
The MDL prevents any metadata changes to these tables, such as
RENAME, TRUNCATE, DROP, ALTER.
While the MDL on the current table prevents dict_table_t::foreign_set
from being modified, it does not prevent the table metadata that the
stored pointers are pointing to from being modified.
The MDL on the child tables will prevent both dict_table_t::referenced_set
as well as the pointed child table metadata from being modified.
wsrep_row_upd_index_is_foreign(): Do not unnecessarily acquire the
data dictionary latch if Galera replication is not enabled.
ha_innobase::can_switch_engines(): Rely on MDL. We are not dereferencing
any pointers stored in the sets.
row_mysql_freeze_data_dictionary(), row_mysql_unfreeze_data_dictionary():
Remove.
row_update_for_mysql(): Call init_fts_doc_id_for_ref() only once.
In ALTER TABLE...IMPORT TABLESPACE and FLUSH TABLES...FOR EXPORT
the SQL layer is protecting the current table with MDL. We do not
need InnoDB latches.
row_undo(): Remove the unnecessary acquisition and release of
dict_sys.latch. This was supposed to prevent the table from being
dropped while the undo log record is being rolled back. But, thanks to
trx_resurrect_table_locks() that was introduced in
mysql/mysql-server@935ba09d52
and commit c291ddfdf7
as well as commit 1bd681c8b3
(MDEV-25506 part 3) tables will be protected against dropping
due to table locks.
This reverts commit 0049d5b515
(which had reverted a previous attempt of fixing this) and addresses
an earlier race condition with the following:
prepare_inplace_alter_table_dict(): If recovered transactions hold
locks on the table while we are executing online ADD INDEX, acquire
a table lock so that the rollback of those recovered transactions will
not interfere with the ADD INDEX.
Since commit 1bd681c8b3 tablespaces are
dropped after the table has been dropped. No dict_sys latch protection
is relevant during the execution of fil_delete_tablespace().
len was containing garbage, since vctempl->mysql_col_offset was
containing old value while calling row_mysql_store_col_in_innobase_format
from innobase_get_computed_value().
It was not updated after the first ALTER TABLE call, because it's INPLACE
logic considered there's nothing to update, and exited immediately from
ha_innobase::inplace_alter_table().
However, vcol metadata needs an update, since vcols structure is changed
in mysql record.
The regression was introduced by 12614af1fe. There, refcount==1 condition
was removed, which turned out to be crucial, though racy. The idea was to
update vc_templ after each (sequencing) ALTER TABLE.
We should do the same another way, and there may be a plenty of solutions,
but the simplest one is to add a following condition:
if vcol structure is changed, drop vc_templ; it will be recreated on next
ha_innobase::open() call.
in prepare_inplace_alter_table. It is safe, since innodb inplace changes
require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which
guarantee MDL_EXCLUSIVE on this stage.
alter_templ_needs_rebuild() also has to track the columns not indexed, to
keep vc_templ correct.
Note that vc_templ is always kept constructed and available after
ha_innobase::open() call, even on INSERT, though no virtual columns are
evaluated during that statement
inside innodb.
In the test case suplied, it will be recreated on the second ALTER TABLE.
ha_innobase::prepare_inplace_alter_table(): Remove always-true conditions.
Near the start of the function, we would already have returned if
no ALTER TABLE operation flags were set that would require special
action from InnoDB.
It turns out that the conditions were redundant already when they were
introduced in mysql/mysql-server@241387a2b6
and in commit 068c61978e.
Thanks to Nikita Malyavin for noticing this.
