Skip to content
/ server Public

MDEV-38726 Assertion `table->default_field != dfield_ptr' failed in b…#4629

Open
bnestere wants to merge 1 commit intomainfrom
main-MDEV-38726
Open

MDEV-38726 Assertion `table->default_field != dfield_ptr' failed in b…#4629
bnestere wants to merge 1 commit intomainfrom
main-MDEV-38726

Conversation

@bnestere
Copy link
Contributor

@bnestere bnestere commented Feb 6, 2026

…ool parse_vcol_defs(THD *, MEM_ROOT *, TABLE *, bool *, vcol_init_mode)

A new assertion added by MDEV-36290 is correct in trying to identify default_fields that weren't correctly accounted in parse_vcol_defs. It caught a case for INSERT DELAYED on tables using TIMESTAMP and DATETIME types with ON UPDATE default values. That is, the insert delayed logic opens the table in one thread, and then copies the field info to another table in the user thread. This copy loses most flag metadata for these fields though. In this case, the flag ON_UPDATE_NOW_FLAG was dropped, and the parse_col_defs() logic was unable to properly account for that default field, and the assertion fired.

This patch proposes two different options for a fix:

Option 1: During the field copy, ensure all flag info is copied from the original field. I'm not sure sure about this though, as the existing logic seems quite clear that only a subset of flags are copied, rather than all.

Option 2: Add ON_UPDATE_NOW_FLAG to be another specific hand-picked flag to be copied.

…ool parse_vcol_defs(THD *, MEM_ROOT *, TABLE *, bool *, vcol_init_mode)

A new assertion added by MDEV-36290 is correct in trying to identify
default_fields that weren't correctly accounted in parse_vcol_defs.
It caught a case for INSERT DELAYED on tables using TIMESTAMP and
DATETIME types with ON UPDATE default values. That is, the insert
delayed logic opens the table in one thread, and then copies the
field info to another table in the user thread. This copy loses most
flag metadata for these fields though. In this case, the flag
ON_UPDATE_NOW_FLAG was dropped, and the parse_col_defs() logic was
unable to properly account for that default field, and the assertion
fired.

This patch proposes two different options for a fix:

Option 1: During the field copy, ensure all flag info is copied from
the original field. I'm not sure sure about this though, as the
existing logic seems quite clear that only a subset of flags are
copied, rather than all.

Option 2: Add ON_UPDATE_NOW_FLAG to be another specific hand-picked
flag to be copied.

Reviewed-by: TODO
Signed-off-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
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.

2 participants