MDEV-37784 Introduce @@new_mode variable #4333

mariadb-RexJohnston · 2025-10-02T05:29:44Z

@@new_mode is a set of flags to control introduced features. Flags are by default off. Setting a flag in @@new_mode will introduce a new different server behaviour and/or set of features.

The Jira issue number for this PR is: MDEV-37784

Description

@@new_mode is a set of flags to control introduced features.
Flags are by default off. Setting a flag in @@new_mode will introduce
a new different server behaviour and/or set of features.

Release Notes

New global and session variable new_mode.
This needs updating.
https://mariadb.com/docs/server/server-management/variables-and-modes/server-system-variables

How can this PR be tested?

TODO: modify the automated test suite to verify that the PR causes MariaDB to behave as intended.
Consult the documentation on "Writing good test cases".

If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.

Basing the PR against the correct MariaDB version

This is a new feature or a refactoring, and the PR is based against the main branch.
This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

spetrunia · 2025-10-02T16:46:40Z

mysql-test/main/mysqld--help.result

 net-read-timeout 30
 net-retry-count 10
 net-write-timeout 60
+new-mode NOW_DEFAULT


What's NOW_DEFAULT ? I think the intent was that by default the variable would be empty.

NOW_DEFAULT is a placeholder for features that were opt-in in previous versions, but are now default.
So for example, we introduce [NEW_MODE_]FIX_DISK_TMPTABLE_COSTS as a flag disabled by default.

#define NEW_MODE_FIX_DISK_TMPTABLE_COSTS (1 << 1)

when we wish to make this default, all we need to do is..

#define NEW_MODE_FIX_DISK_TMPTABLE_COSTS (1 << 0)

We wont need to (though we should) change the actual code itself.

spetrunia · 2025-10-02T16:50:20Z

sql/sys_vars.cc

+
+static Sys_var_set Sys_new_behavior(
+       "new_mode",
+       "Used to introduce new behavior to new MariaDB versions",


I think we can introduce new behavior to new versions just fine.
@@new_mode's purpose is to allow new behaviors to be added to OLD versions. Where we have to have them switchable and disabled by default.

I'll change the wording.

spetrunia · 2025-10-02T17:29:53Z

mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result

+NUMERIC_MIN_VALUE	NULL
+NUMERIC_MAX_VALUE	NULL
+NUMERIC_BLOCK_SIZE	NULL
+ENUM_VALUE_LIST	NOW_DEFAULT,FIX_DISK_TMPTABLE_COSTS,FIX_SEMIJOIN_DUPS_WEEDOUT_CHECK,TEST_WARNING1,TEST_WARNING2


Is it feasible to get rid of TEST_WARNINGs here?

We don't want to see NOW_DEFAULT either, since it is pointless setting this. Looking...

I can introduce a set of "hidden" values in Sys_var_typelib, default empty.

@@new_mode is a set of flags to control introduced features. Flags are by default off. Setting a flag in @@new_mode will introduce a new different server behaviour and/or set of features. We also introduce a new option 'hidden_values' into some system variable types to hide options that we do not wish to show as options.

spetrunia · 2025-10-03T06:05:58Z

Ouch, I've made a mistake: pushed another fix into this PR branch, 11.8-MDEV-37784. Sorry for any inconvenience.

spetrunia · 2025-10-03T08:03:51Z

So, mysqld --help --verbose output still mentions hidden names:

                      versions. Any combination of: NOW_DEFAULT, 
                      FIX_DISK_TMPTABLE_COSTS, FIX_SEMIJOIN_DUPS_WEEDOUT_CHECK,
                      TEST_WARNING1, TEST_WARNING2, or ALL to set all
                      combinations

spetrunia · 2025-10-03T08:08:01Z

MariaDB [test]> set @@new_mode='ALL';
Query OK, 0 rows affected, 2 warnings (0.001 sec)

MariaDB [test]> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 4209 | 'TEST_WARNING1' is default and ignored |
| Warning | 4209 | 'TEST_WARNING2' is default and ignored |
+---------+------+----------------------------------------+
2 rows in set (0.000 sec)

I would expect the warnings not to be there...

dr-m · 2025-10-03T08:22:17Z

Has the name new_mode been carefully thought through? It could get old quickly. I’m grateful that more than 20 years ago, someone opposed my lazy proposal of ROW_FORMAT=NEW and MySQL 5.0.3 got ROW_FORMAT=COMPACT instead. The ROW_FORMAT=NEW would have gotten embarrassing when ROW_FORMAT=DYNAMIC was reused by InnoDB some years later.

Possible replacements of the word ‘new’ would include ‘extended’ or ‘backported’. Perhaps some native English speakers can think of even better alternatives?

spetrunia · 2025-10-03T09:36:09Z

@dr-m , well, old_mode is already there.
This is different from row_format=new, which won't be new in a few years.
new_mode is a set of flags which will appear and eventually disappear.

- Don't print hidden values in mysqld --help output. - Better function names and formatting.

- Make get_options() use the same logic as check_new_mode_value() does. - More renames

spetrunia · 2025-10-03T11:29:18Z

.. pushed 3 commits with obvious fixes.
One thing that's still not clear to me: @mariadb-RexJohnston , what is NOW_DEFAULT and why is it needed?

mariadb-RexJohnston · 2025-10-03T16:35:05Z

If we are to be able to change the behaviour by changing our flags and leaving the rest of the codebase alone when a feature transitions from 'beta' to 'default' (which i think will be an important property), we need the evaluation of

thd->variables.new_mode & NEW_MODE_FEATURE_BECOMING_DEFAULT

to be non-zero, so some bit in thd->variables.new_mode needs to be non-zero.
NOW_DEFAULT is that bit.
We redefine NEW_MODE_FEATURE_BECOMING_DEFAULT from whatever bit it used to be, to the same as the default bit and the feature is now by default, enabled.

spetrunia · 2025-10-03T18:30:12Z

That's internal reason. Let's look at this from the user point of view.
From the user point of view, NOW_DEFAULT doesn't seem to make much sense.

If we are to be able to change the behaviour by changing our flags and leaving the rest of the codebase alone when a feature transitions from 'beta' to 'default' (which i think will be an important property), we need the evaluation of

thd->variables.new_mode & NEW_MODE_FEATURE_BECOMING_DEFAULT

Two points:
A. I actually expect us to remove the logic providing the old behavior.
The only remainder would be an entry in new_mode_all_names, so if somebody upgrades but doesn't edit their my.cnf, they do not get errors.

What if for some reason we want the logic in the code to remain?
I think this can also be achieved. In the patch for MDEV-37732, I already have the check in this form

    if (optimizer_new_mode(thd, NEW_MODE_FIX_SEMIJOIN_DUPS_WEEDOUT_CHECK) &&

optimizer_new_mode at the moment is

inline bool optimizer_new_mode(const THD *thd, ulonglong mode_flag)
{            
  return (thd->variables.new_behavior & mode_flag);
}

We could introduce

#define NEW_MODE_VALUE_FOR_ENABLED_ALWAYS  number

and then eventually we would do

#define NEW_MODE_FIX_SEMIJOIN_DUPS_WEEDOUT_CHECK  NEW_MODE_VALUE_FOR_ENABLED_ALWAYS

and then optimizier_new_mode() would return true for NEW_MODE_VALUE_FOR_ENABLED_ALWAYS regardless of thd->variables.new_behavior setting.

dr-m · 2025-10-06T06:02:15Z

storage/innobase/handler/ha_innodb.cc

 	array_elements(innodb_linux_aio_names) - 1,
 	"innodb_linux_aio_typelib",
 	innodb_linux_aio_names,
-	NULL
+	NULL, NULL
 };
 #endif


What is this change about? Why is it needed? There is no mention of this in the commit message.

TYPELIB is changed, so every TYPELIB static initializer has to be too. I'll change this place to use CREATE_TYPELIB_FOR() macro (like few lines above)

svoj added External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. MariaDB Corporation and removed External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. labels Oct 2, 2025

spetrunia reviewed Oct 2, 2025

View reviewed changes

spetrunia force-pushed the 11.8-MDEV-37784 branch from fb5c53c to 0785e75 Compare October 2, 2025 18:37

mariadb-RexJohnston force-pushed the 11.8-MDEV-37784 branch 2 times, most recently from d54ab4f to df8f699 Compare October 2, 2025 22:59

mariadb-RexJohnston force-pushed the 11.8-MDEV-37784 branch from df8f699 to 714b1ce Compare October 3, 2025 00:14

spetrunia added 2 commits October 3, 2025 13:27

Review input part 1

b037738

- Don't print hidden values in mysqld --help output. - Better function names and formatting.

Review input part 2:

ed803c1

- Make get_options() use the same logic as check_new_mode_value() does. - More renames

spetrunia force-pushed the 11.8-MDEV-37784 branch from 714b1ce to ed803c1 Compare October 3, 2025 10:59

Review input part 2: setting @@new_mode=ALL shouldn't give warnings.

64ae315

dr-m requested changes Oct 6, 2025

View reviewed changes

Uh oh!

MDEV-37784 Introduce @@new_mode variable #4333

Are you sure you want to change the base?

MDEV-37784 Introduce @@new_mode variable #4333

Uh oh!

Conversation

mariadb-RexJohnston commented Oct 2, 2025

Description

Release Notes

How can this PR be tested?

Basing the PR against the correct MariaDB version

PR quality check

Uh oh!

spetrunia Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

mariadb-RexJohnston Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spetrunia Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

mariadb-RexJohnston Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

spetrunia Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

mariadb-RexJohnston Oct 2, 2025

Choose a reason for hiding this comment

Uh oh!

mariadb-RexJohnston Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

dr-m commented Oct 3, 2025

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

mariadb-RexJohnston commented Oct 3, 2025

Uh oh!

spetrunia commented Oct 3, 2025

Uh oh!

dr-m Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

vuvova Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mariadb-RexJohnston Oct 2, 2025 •

edited

Loading

mariadb-RexJohnston Oct 2, 2025 •

edited

Loading