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

Shrink my_thread_id to uint32_t

Details

    Description

      my_thread_id, the type of many thread_id variables/functions, is a readability typedef of uint64 de jure, but long-standing formats (such as the client-server protocol and the binary log) hard-coded `my_thread_id` to 32 bits in practice. In fact –

      In mysqld.cc, static recalculate_thread_id_range() places a grand limit of (0, UINT_MAX32) on my_thread_id next_thread_id(void) and aborts the program when there’re “2^32 connections”.

      To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of uint32_t to reflect its de facto range.

      There appears to be thread_id-named variables/functions that don’tcan’t make use of the my_thread_id typedef – some are ulonglong (64-bit) and some ulong/unsigned long (64-bit on Linux, 32-bit on Windows) (including slave_proxy_id of sql/log_event.h, the old name of pseudo_thread_id).
      Any thread_id users among them should convert to my_thread_id to join the consistency’s cause.
      (I tried to do this as part of MDEV-35646; a few files in but none understood uintXX of my_global.h (nor uintXX_t of MDEV-35460).

      Attachments

        Issue Links

          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15089 Ensure that connection ID is in 32bit range

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35646 pseudo_thread_id Can Overflow on Binlog Write

          • Major - Major loss of function.
          • Closed
          split to

          Task - A task that needs to be done. MDEV-35707 Sys_var_XXX types should be fixed-typed, not by how many ‘long’s

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

          Activity

            Ascending order - Click to sort in descending order
            ParadoxV5 Jimmy Hú created issue -
            ParadoxV5 Jimmy Hú made changes -
            Field Original Value New Value
            ParadoxV5 Jimmy Hú made changes -
            Summary Shrink my_thread_it to uint32_t Shrink my_thread_id to uint32_t
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of C/C++ Standard).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of MDEV-35460).
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            Labels tech_debt
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but due to binary log format specifications, only 4 bytes are valid (MDEV-15089). In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of MDEV-35460).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but long-standing formats (such as the client-server protocol and the binary log (MDEV-15089)) hard-coded `my_thread_id` to 32 bits in practice. In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of MDEV-35460).
            ParadoxV5 Jimmy Hú made changes -
            Description {{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but long-standing formats (such as the client-server protocol and the binary log (MDEV-15089)) hard-coded `my_thread_id` to 32 bits in practice. In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of MDEV-35460).             		{{my_thread_id}}, the type of many {{thread_id}} variables/functions, is a readability typedef of {{uint64}} _de jure_, but long-standing formats (such as the client-server protocol and the binary log) hard-coded `my_thread_id` to 32 bits in practice. In fact –
            bq. In {{mysqld.cc}}, {{static recalculate_thread_id_range()}} places a grand limit of {{(0, UINT_MAX32)}} on {{my_thread_id next_thread_id(void)}} and aborts the program when there’re “2^32 connections”.

            To prevent inconsistent-size bugs (such as MDEV-35646) once and for all, we should change it to a typedef of {{uint32_t}} to reflect its _de facto_ range.

            There appears to be {{thread_id}}\-named variables/functions that -don’t-+can’t+ make use of the {{my_thread_id}} typedef – some are {{ulonglong}} (64-bit) and some {{ulong}}/{{unsigned long}} (64-bit on Linux, 32-bit on Windows) (including {{slave_proxy_id}} of {{sql/log_event.h}}, the old name of {{pseudo_thread_id}}).
            Any {{thread_id}} users among them should convert to {{my_thread_id}} to join the consistency’s cause.
            (I tried to do this as part of MDEV-35646; a few files in but none understood {{uintXX}} of {{my_global.h}} (nor {{uintXX_t}} of MDEV-35460).
            ParadoxV5 Jimmy Hú added a comment -

            It could also have been wise to move typedef and #define out of my_pthread.h - because , my_pthread.h has nothing to do with connection ids (traditionally misnamed thread_id). my_pthread.h was for OS threads.
            ⸺ wlad, https://github.com/MariaDB/server/pull/3721#issuecomment-2602806765

            ParadoxV5 Jimmy Hú added a comment - It could also have been wise to move typedef and #define out of my_pthread.h - because , my_pthread.h has nothing to do with connection ids (traditionally misnamed thread_id). my_pthread.h was for OS threads. ⸺ wlad , https://github.com/MariaDB/server/pull/3721#issuecomment-2602806765

            People

              Unassigned Unassigned
              ParadoxV5 Jimmy Hú
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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