Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6138

show sysvar's help in I_S tables

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.1.1
    • OTHER
    • None

    Description

      Every sysvar has an associated help text, but it's only accessible as mysqld --help which is kind of a waste. It would be helpful to show it as a third column in INFORMATION_SCHEMA.GLOBAL_VARIABLES and INFORMATION_SCHEMA.SESSION_VARIABLES. For backward compatibility we'll hide this column if @@old_mode=NO_SYSVAR_HELP.

      Alternatively, we could introduce a new table, say, INFORMATION_SCHEMA.SYSTEM_VARIABLES with all (global and session) variables, without their current values, but with the help, type, valid value range, etc.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-8579 Some sysvars in I_S are missing any meaningful help (comment) text

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            if we extend existing I_S tables, then we can at the same time extend I_S.PLUGIN and I_S.COLLATION to show usage counters (that now only feedback plugin can show). In this case the better name for the old mode would be something like OLD_I_S_TABLES

            serg Sergei Golubchik added a comment - if we extend existing I_S tables, then we can at the same time extend I_S.PLUGIN and I_S.COLLATION to show usage counters (that now only feedback plugin can show). In this case the better name for the old mode would be something like OLD_I_S_TABLES
            monty Michael Widenius added a comment -

            When doing this, we should also show the following:

            • Default value
            • How the value was set. One of
            • Default value, Set-by-config-file, Set-by-user, auto-configured (ie, tunned by the server depending on other values)
            monty Michael Widenius added a comment - When doing this, we should also show the following: Default value How the value was set. One of Default value, Set-by-config-file, Set-by-user, auto-configured (ie, tunned by the server depending on other values)
            simon.mudd Simon J Mudd added a comment -

            Also missing if the global value is static or not.

            • some variables are set on startup (so static)
            • others can be changed at any time (so dynamic)
            • others can be changed only when replication is stopped (slave_parallel_workers in MySQL 5.6. There may be something similar in MariaDB). Indicating variables which can only be changed (or their behaviour is picked up) "at certain points in time" would also be useful.

            Perhaps, adding a time of last_update would be useful. I've seen already with P_S that having the stats is great but if you don't know how long they have been configured that way it might be an issue. So perhaps an extra column of the form:

            last_change TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP (or "boot time"...) might be useful.

            simon.mudd Simon J Mudd added a comment - Also missing if the global value is static or not. some variables are set on startup (so static) others can be changed at any time (so dynamic) others can be changed only when replication is stopped (slave_parallel_workers in MySQL 5.6. There may be something similar in MariaDB). Indicating variables which can only be changed (or their behaviour is picked up) "at certain points in time" would also be useful. Perhaps, adding a time of last_update would be useful. I've seen already with P_S that having the stats is great but if you don't know how long they have been configured that way it might be an issue. So perhaps an extra column of the form: last_change TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP (or "boot time"...) might be useful.
            serg Sergei Golubchik added a comment -

            Yes, I'll have the information about static/dynamic. But, probably, not the timestamp — this would have a rather high relative overhead (like 3x – 100x storage overhead, depending on the implementation).

            serg Sergei Golubchik added a comment - Yes, I'll have the information about static/dynamic. But, probably, not the timestamp — this would have a rather high relative overhead (like 3x – 100x storage overhead, depending on the implementation).
            serg Sergei Golubchik added a comment -

            at the end, I decided to keep old tables and create a new one instead:

            MariaDB [test]> select * from information_schema.system_variables where variable_name='completion_type'\g
            		 
            *************************** 1. row ***************************
            		 
                    VARIABLE_NAME: COMPLETION_TYPE
            		 
                    SESSION_VALUE: CHAIN
            		 
                     GLOBAL_VALUE: NO_CHAIN
            		 
              GLOBAL_VALUE_ORIGIN: COMPILE-TIME
            		 
                    DEFAULT_VALUE: NO_CHAIN
            		 
                   VARIABLE_SCOPE: SESSION
            		 
                    VARIABLE_TYPE: ENUM
            		 
                 VARIABLE_COMMENT: The transaction completion type
            		 
                NUMERIC_MIN_VALUE: NULL
            		 
                NUMERIC_MAX_VALUE: NULL
            		 
               NUMERIC_BLOCK_SIZE: NULL
            		 
                  ENUM_VALUE_LIST: NO_CHAIN,CHAIN,RELEASE
            		 
                        READ_ONLY: NO
            		 
            COMMAND_LINE_ARGUMENT: REQUIRED
            		 
            1 row in set (0.00 sec)

            serg Sergei Golubchik added a comment - at the end, I decided to keep old tables and create a new one instead: MariaDB [test]> select * from information_schema.system_variables where variable_name='completion_type'\g *************************** 1. row *************************** VARIABLE_NAME: COMPLETION_TYPE SESSION_VALUE: CHAIN GLOBAL_VALUE: NO_CHAIN GLOBAL_VALUE_ORIGIN: COMPILE-TIME DEFAULT_VALUE: NO_CHAIN VARIABLE_SCOPE: SESSION VARIABLE_TYPE: ENUM VARIABLE_COMMENT: The transaction completion type NUMERIC_MIN_VALUE: NULL NUMERIC_MAX_VALUE: NULL NUMERIC_BLOCK_SIZE: NULL ENUM_VALUE_LIST: NO_CHAIN,CHAIN,RELEASE READ_ONLY: NO COMMAND_LINE_ARGUMENT: REQUIRED 1 row in set (0.00 sec)

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.