Skip to content

MDEV-41344 Timestamp conversion does not work for TRADITIONAL mode - #5786

Merged
midenok merged 1 commit into
11.8from
11.8-midenok-MDEV-41344
Oct 1, 2026
Merged

midenok merged 1 commit into
11.8from
11.8-midenok-MDEV-41344

Conversation

@midenok

@midenok midenok commented Sep 29, 2026

Copy link
Copy Markdown
Contributor

Field_temporal::get_copy_func() returns do_field_datetime whenever the session's sql_mode has NO_ZERO_DATE or NO_ZERO_IN_DATE (e.g. under sql_mode=TRADITIONAL), or when the two fields are not eq_def(), regardless of whether the field is a system-versioned row_end.

get_copy_func() checked for that value and returned early, before ever reaching the VERS_ROW_END check that installs
do_field_versioned_timestamp. So an ALTER TABLE .. FORCE meant to convert an old-format row_end silently copied the value unchanged instead: the conversion check correctly demanded a copy, but the copy step never applied it, with no error or warning.

The fix checks the row_end conversion need first, independently of what Field_temporal::get_copy_func() picked. row_end is server-maintained and never zero, so NO_ZERO_DATE does not apply to it.

Tested by "traditional" combination in old_timestamp.test, the test restores real pre-11.5 row_end fixtures and runs mariadb-upgrade --force.

Copilot AI balanced review requested due to automatic review settings September 29, 2026 12:05

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Field_temporal::get_copy_func() returns do_field_datetime whenever the
session's sql_mode has NO_ZERO_DATE or NO_ZERO_IN_DATE (e.g. under
sql_mode=TRADITIONAL), or when the two fields are not eq_def(),
regardless of whether the field is a system-versioned
row_end.

get_copy_func() checked for that value and returned early, before ever
reaching the VERS_ROW_END check that installs
do_field_versioned_timestamp. So an ALTER TABLE .. FORCE meant to
convert an old-format row_end silently copied the value unchanged
instead: the conversion check correctly demanded a copy, but the copy
step never applied it, with no error or warning.

The fix checks the row_end conversion need first, independently of
what Field_temporal::get_copy_func() picked. row_end is
server-maintained and never zero, so NO_ZERO_DATE does not apply to
it.

Tested by "traditional" combination in old_timestamp.test, the test
restores real pre-11.5 row_end fixtures and runs mariadb-upgrade
--force.
@midenok
midenok force-pushed the 11.8-midenok-MDEV-41344 branch from d6569e7 to 524f009 Compare October 1, 2026 17:32
@midenok
midenok enabled auto-merge (rebase) October 1, 2026 17:48
@midenok
midenok force-pushed the 11.8-midenok-MDEV-41344 branch from 8f89e99 to 524f009 Compare October 1, 2026 19:24
@midenok
midenok merged commit dddbd5f into 11.8 Oct 1, 2026
16 of 20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

5 participants