MDEV-39609 - SIGSEGV in process_i_s_table_temporary_tables after failed ALTER TABLE on temporary TIMESTAMP table with CHECK constraint - #5439
Open
pranavktiwari wants to merge 1 commit into
Open
Conversation
Contributor
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
There was a problem hiding this comment.
Pull request overview
Adjusts FRM-handling session sql_mode sanitization to additionally clear strict and “no zero date” flags, likely to make .frm parsing/field conversion more permissive during metadata operations.
Changes:
- Extend the
Sql_mode_save_for_frm_handlingmask to also clearMODE_STRICT_*andMODE_NO_ZERO_*flags. - (Suggested) Align the indentation of the mask continuation lines for readability.
- (Suggested) Update the nearby explanatory comment to reflect the newly-cleared modes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
pranavktiwari
changed the title
pranavktiwari
force-pushed
the
11.4-MDEV-39609
branch
2 times, most recently
from
July 23, 2026 09:50
35eb680 to
2928ac7
Compare
pranavktiwari
changed the title
…ed ALTER TABLE on temporary TIMESTAMP table with CHECK constraint Problem: SELECT * FROM information_schema.tables crashed with a SIGSEGV in process_i_s_table_temporary_tables() after a failed strict-mode ALTER TABLE on a TEMPORARY table with a zero-default TIMESTAMP column and a CHECK constraint. Cause: The failed ALTER marks the temp table needs_reopen. On reopen, Sql_mode_save_for_frm_handling relaxed only parser flags, not the strict/zero-date ones, so evaluating the stored zero TIMESTAMP default was escalated to ER_WRONG_VALUE. open_temporary_table() then failed, leaving the TMP_TABLE_SHARE in temporary_tables with an empty all_tmp_tables. The I_S iteration walked into that empty share and dereferenced a NULL TABLE. Regression in 11.4. Fix: Broadened Sql_mode_save_for_frm_handling to also clear MODE_STRICT_TRANS_TABLES, MODE_STRICT_ALL_TABLES, MODE_NO_ZERO_DATE, and MODE_NO_ZERO_IN_DATE while parsing FRM-stored defaults/expressions. Reopening an already-validated temp table now succeeds in any sql_mode, so the empty share is never created and the crash is gone; strictness still applies when new values are written.
pranavktiwari
force-pushed
the
11.4-MDEV-39609
branch
from
July 24, 2026 06:17
2928ac7 to
8b93a93
Compare
midenok
self-requested a review
July 31, 2026 09:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fixes MDEV-39609
Problem:
SELECT * FROM information_schema.tables (and SHOW TABLES) crashed with a SIGSEGV in process_i_s_table_temporary_tables() after a failed strict-mode ALTER TABLE on a TEMPORARY table with a zero-default TIMESTAMP column and a CHECK constraint.
Cause:
The failed ALTER marks the temp table needs_reopen. On reopen, Sql_mode_save_for_frm_handling relaxed only parser flags, not the strict/zero-date ones, so evaluating the stored zero TIMESTAMP default was escalated to ER_WRONG_VALUE. open_temporary_table() then failed, leaving the TMP_TABLE_SHARE in temporary_tables with an empty all_tmp_tables. The I_S iteration walked into that empty share and dereferenced a NULL TABLE. Regression in 11.4.
Fix:
Broadened Sql_mode_save_for_frm_handling to also clear MODE_STRICT_TRANS_TABLES, MODE_STRICT_ALL_TABLES, MODE_NO_ZERO_DATE, and MODE_NO_ZERO_IN_DATE while parsing FRM-stored defaults/expressions. Reopening an already-validated temp table now succeeds in any sql_mode, so the empty share is never created and the crash is gone; strictness still applies when new values are written.