MDEV-39418: Merge 11.4 into 11.8 - null-merge MDEV-39240#4976
MDEV-39418: Merge 11.4 into 11.8 - null-merge MDEV-39240#4976itzanway wants to merge 1 commit intoMariaDB:11.8from
Conversation
Problem:
When a stored routine involes a cursor and metadata of table on which
the cursor is defined changes, the SP instruction has to be reparsed.
For ex:
CREATE OR REPLACE TABLE t1 (a INT);
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;
SELECT f1(); - first execution, sp-mem_root marked read-only on exec
SELECT f1(); - read-only sp-mem_root
ALTER TABLE t1 MODIFY a TEXT; - metadta change
SELECT f1(); - reparse, rerun instr and mark new mem_root read-only
sp_lex_instr is re-parsed after the metadata change, which sets up a
new mem_root for reparsing. Once the instruction is re-parsed and
re-executed(via reset_lex_and_exec_core), the new memory root assigned
to the instruction being reparsed remains writable. This violates the
invariant of SP memory root protection.
Fix:
Mark the new memory root created for reparsing with read-only flag,
after the first execution of the SP instruction.
itzanway
force-pushed
the
bb-11.8-merge-q2-2026
branch
from
a96f1ae to
a775788
Compare
|
The two required CI failures (amd64-ubuntu-2204-debug-ps and amd64-windows-packages) appear to be pre-existing flaky tests unrelated to this change. Both federated.federated and federated.federatedx_mdev39196 are failing consistently across multiple unrelated commits and branches in the CI grid (e.g. refs/pull/4876/head, refs/pull/4939/head, bb-10.11-midenok), indicating an environment-level issue rather than a regression introduced here. |
|
I've documented PR in MDEV-39403 |
grooverdan
added
the
External Contribution
|
The full CI status of 11.8 is https://buildbot.mariadb.org/#/grid?branch=11.8 or for a search of test failures cr. Some unstable test investigation has been done on https://jira.mariadb.org/browse/MDEV-39280 - but any other missing gaps please do note them. I'm not 100% sure what a null merge would look like but this looks like a squashed commit. I'd expect it to be at least a merge. I'm not sure if its workable to make a null merge PR as pull requests have some troubles manipulating when they have merges. Maybe the documentation in the merge MDEV is good enough. |
|
Hi @sanja-byelkin — could you take a look at this when you get a chance? It's a straightforward null-merge of 11.4 → 11.8 for the Q2 2026 release, with MDEV-39240 excluded as it doesn't apply to 11.8. @grooverdan — a couple of follow-ups: On the CI failures: The two required failures ( On the null-merge format: I understand your concern about this looking like a squashed commit rather than a merge. I'm happy to restructure it as a proper merge commit if that's preferred — just let me know. Alternatively, if the MDEV-39403 documentation is sufficient for tracking purposes, I can leave it as-is. Whatever works best for the team. |
gkodinov
changed the title
|
I do not think this commits presented here are readable. Normally, in a merge-up situation, IMHO, one would get the full set of changes by all commits and then add a revert commit for one or more changes. |
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Forfeiting my review rights by approving it.
5 participants
Merge branch 11.4 into 11.8 as part of the Q2 2026 release.
MDEV-39240 is null-merged (excluded) as if removed by MDEV-32188.
MDEV-39240 fixed a replication issue where pre-11.5 replicas accepted
timestamps beyond Year 2038 via row-based replication, introduced as a
side effect of MDEV-32188 being a preview feature in 11.4. In 11.8,
MDEV-32188 is fully released and the extended timestamp range is stable,
so MDEV-39240 does not apply and must not be merged.
This was requested by Jimmy Hú in the Q2 2026 release task (MDEV-39403).
I confirm this contribution is provided under the BSD New 3-Clause License.