Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.4
-
None
Description
I run this script in 11.4:
DELIMITER /
|
CREATE OR REPLACE FUNCTION f1() RETURNS INT |
BEGIN
|
DECLARE vc INT DEFAULT 0; |
DECLARE cur CURSOR FOR SELECT a FROM t1; |
OPEN cur; |
FETCH cur INTO vc; |
CLOSE cur; |
RETURN vc; |
END; |
/
|
DELIMITER ;
|
Now I set a break point in sp_instr_cpush::exec_core() and every time it breaks I print the following:
p thd->lex->query_arena()->mem_root->flags & ROOT_FLAG_READ_ONLY
|
The I run this script:
CREATE OR REPLACE TABLE t1 (a INT); |
INSERT INTO t1 VALUES (10); |
SELECT f1(); -- flags==0 (1a) |
SELECT f1(); -- flags==4 (2a) |
SELECT f1(); -- flags==4 (3a) |
ALTER TABLE t1 MODIFY a TEXT; |
SELECT f1(); -- flags==4, the called again with flag==0 (1b) |
SELECT f1(); -- flags==0 (2b) |
SELECT f1(); -- flags==0 (3b) |
Comment:
- At the first call for f1() in (1a) the flag is equal to zero, i.e. ROOT_FLAG_READ_ONLY is not set. Then at the end of the f1() execution the query arena gets marked with the ROOT_FLAG_READ_ONLY flag (in the end of sp_head::execute). This is correct.
- During the next two calls of f1() in (2a) and (3a) the flag ROOT_FLAG_READ_ONLY stays. This is correct: the memory root is protected agains changes.
- Then ALTER is executed.
- The first call for f1() after the ALTER in (1b) executes sp_instr_cpush::exec_core() twice. In the first call the flag ROOT_FLAG_READ_ONLY still presents. In the second call the flag is not present. This also seems correct.
- The second and the third call for f1() in (2b) and (3b) after the ALTER says that the flag is not set! This does not look correct. It's expected that it gets marked with ROOT_FLAG_READ_ONLY again, like on the second and the first call for f1() before the ALTER.
So the protection against the memory root modification disappeares after a metadata change. Looks wrong.
Attachments
Issue Links
- is caused by
-
MDEV-5816 MySQL WL#4179 - Stored programs: validation of stored program statements
-
- Closed
-