mirror of
https://github.com/MariaDB/server.git
synced 2025-10-13 03:09:24 +02:00
7d46ee3336
This split from MDEV-32294, discovered when inspecting how Item_subselect::used_tables_cache gets recalculated during 1st and 2nd executions of prepared statements. We build a list of outer references resolved against each select_lex. This list is not reset at the end of a prepared statement, so each element in this must be allocated on statement memory. Because of this we rely on MDEV-30073, as prior to this patch, some outer references are freed at the end of prepared statement execution. We use this list to recalculate Item_subselect::used_tables_cache There are a number of additional processing steps that need to happen during query merges. A derived table merge will leave a mix of SELECT_LEX::nest_base_level pointers in our query structure. Some Item::*processors will search for items that 'belong' only to the 'unit' being searched. We need to update this and nest_level when merging. We update SELECT_LEX::outer_references_resolved_here, in case an Item in a subquery is no longer an outer reference. We introduce a number tests in main.outer_reference, along with a way of wrapping each select to be executed in a number of different ways. TODO, check that the result of each of these different ways of execution is identical. We could wrap this into client/mysqltest and perhaps allow stacking of each execution method, such as --view (to create a view from our test statement and then select from the view) and --ps (to prepare our test statement, now selecting from a view, and compare data output from first and second executions). Name resolution fixes related to prepared statement execution. We no longer call fix_outer_field after the first execution, we now rely on the attribute depended_from, populated during the first execution. Code is added to Item_field::fix_fields to compensate. We allocate view field substituions on statement memory. When run as a prepared statement, this happens during the first execution. table_map fixes related to prepared statement and view processing. In setup_fields, during the 2nd execution of a prepared statement, we can call used_tables() prior to any caches being set up. This can result in incorrect processing. We also ban execution of EXPLAIN EXTENDED statements during mtr ps protocol runs as the generation of warnings varies due to the fact that some Item select_transformers cannot be run during execution of the prepare statement, so we would normally expect a different warning output. |
||
|---|---|---|
| .. | ||
| archive | ||
| atomic | ||
| binlog | ||
| binlog_encryption | ||
| client | ||
| compat | ||
| csv | ||
| encryption | ||
| engines | ||
| federated | ||
| funcs_1 | ||
| funcs_2 | ||
| galera | ||
| galera_3nodes | ||
| galera_3nodes_sr | ||
| galera_sr | ||
| gcol | ||
| handler | ||
| heap | ||
| innodb | ||
| innodb_fts | ||
| innodb_gis | ||
| innodb_i_s | ||
| innodb_zip | ||
| jp | ||
| json | ||
| large_tests | ||
| maria | ||
| mariabackup | ||
| mtr/t | ||
| mtr2 | ||
| multi_source | ||
| optimizer_unfixed_bugs | ||
| parts | ||
| perfschema | ||
| perfschema_stress | ||
| period | ||
| plugins | ||
| roles | ||
| rpl | ||
| s3 | ||
| sql_sequence | ||
| storage_engine | ||
| stress | ||
| sys_vars | ||
| sysschema | ||
| unit | ||
| vcol | ||
| versioning | ||
| wsrep | ||