1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00

Merge branch '10.2' into 10.3

This commit is contained in:
Oleksandr Byelkin
2022-05-03 10:59:54 +02:00
111 changed files with 2663 additions and 552 deletions

View File

@ -5143,6 +5143,7 @@ public:
int get_all_tables(THD *thd, TABLE_LIST *tables, COND *cond)
{
DBUG_ENTER("get_all_tables");
LEX *lex= thd->lex;
TABLE *table= tables->table;
TABLE_LIST table_acl_check;
@ -5160,7 +5161,29 @@ int get_all_tables(THD *thd, TABLE_LIST *tables, COND *cond)
uint table_open_method= tables->table_open_method;
bool can_deadlock;
MEM_ROOT tmp_mem_root;
DBUG_ENTER("get_all_tables");
/*
We're going to open FRM files for tables.
In case of VIEWs that contain stored function calls,
these stored functions will be parsed and put to the SP cache.
Suppose we have a view containing a stored function call:
CREATE VIEW v1 AS SELECT f1() AS c1;
and now we're running:
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME=f1();
If a parallel thread invalidates the cache,
e.g. by creating or dropping some stored routine,
the SELECT query will re-parse f1() when processing "v1"
and replace the outdated cached version of f1() to a new one.
But the old version of f1() is referenced from the m_sp member
of the Item_func_sp instances used in the WHERE condition.
We cannot destroy it. To avoid such clashes, let's remember
all old routines into a temporary SP cache collection
and process tables with a new empty temporary SP cache collection.
Then restore to the old SP cache collection at the end.
*/
Sp_caches old_sp_caches;
old_sp_caches.sp_caches_swap(*thd);
bzero(&tmp_mem_root, sizeof(tmp_mem_root));
@ -5334,6 +5357,13 @@ err:
thd->restore_backup_open_tables_state(&open_tables_state_backup);
free_root(&tmp_mem_root, 0);
/*
Now restore to the saved SP cache collection
and clear the temporary SP cache collection.
*/
old_sp_caches.sp_caches_swap(*thd);
old_sp_caches.sp_caches_clear();
DBUG_RETURN(error);
}