Fix inconsistent definition of PERFORMANCE_SCHEMA.REPLICATION_APPLIER_STATUS.COUNT_TRANSACTIONS_RETRIES column

This column (`COUNT_TRANSACTIONS_RETRIES`) is defined as `BIGINT UNSIGNED` (64-bit unsigned integer) in the user-visible SQL definition: https://github.com/MariaDB/server/blob/182ff21ace34ea4f00fb5b66689b172323d91f99/storage/perfschema/table_replication_applier_status.cc#L66 "COUNT_TRANSACTIONS_RETRIES BIGINT unsigned not null comment 'The number of retries that were made because the replication SQL thread failed to apply a transaction.'," And its value is internally set/updated using the `set_field_ulonglong` function: https://github.com/MariaDB/server/blob/182ff21ace34ea4f00fb5b66689b172323d91f99/storage/perfschema/table_replication_applier_status.cc#L231-L233 case 3: /* total number of times transactions were retried */ set_field_ulonglong(f, m_row.count_transactions_retries); break; … but the structure where it is stored allocates only `ulong` for it: https://github.com/MariaDB/server/blob/182ff21ace34ea4f00fb5b66689b172323d91f99/storage/perfschema/table_replication_applier_status.h#L62 ulong count_transactions_retries; As a result of this inconsistency: 1. On any platform where `ulong` is `uint32_t` and `ulonglong` is `uint64_t`, setting this value would corrupt the 4 bytes of memory *following* the 4 bytes actually allocated for it. Likely this problem was never noticed because this is the final element in the structure, and the structure is padded by the compiler to prevent memory corruption errors. 2. On any BIG-ENDIAN platform where `ulong` is `uint32_t` and `ulonglong` is `uint64_t`, reading back the value of this column will result in total garbage. Likely this problem was never noticed because MariaDB has not been tested on 32-bit big-endian platforms. In order not to affect the user-visible/SQL definition of this column, the correct way to fix this issue is to change it to `ulonglong` in the structure definition. See https://github.com/MariaDB/server/pull/2763/files#r1329110832 for the original identification and discussion of this issue. All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services

Author: dlenski

storage/perfschema/table_replication_applier_status.h

@@ -61,7 +61,7 @@ struct st_row_applier_status {
  enum_rpl_yes_no service_state;
  uint remaining_delay;
  bool remaining_delay_is_set;
- ulong count_transactions_retries;
+ ulonglong count_transactions_retries;
 };
 
 /** Table PERFORMANCE_SCHEMA.replication_applier_status */