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

Row-based replication DATETIME(m) to DATETIME(s) does not work or incorrect

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL)
    • 10.4(EOL)
    • Replication
    • None

    Description

      When Master sets up @@global.mysql56_temporal_format=0
      to create a table with DATETIME(m) column its row-based format image does not include the precision
      which therefore is unknown by Slave. When master and slave precisions are different (m \not= s) both lossy and non-lossy replication fail. Consequently fails DATATIME(m) to DATE because inferred conversion involves
      DATETIME(m) to DATETIME(0) at the first stage.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17098 DATE -> DATETIME replication conversion not working, even in ALL_NON_LOSSY mode

          • Major - Major loss of function.
          • Closed

          Activity

            Elkin Andrei Elkin added a comment -

            Here is an ASAN stack as a consequence of losing the original m precision. As noted the original DATETIME(m) field arrives with zero metadata which made it to interpret as DATETIME(0). That caused incorrect unpacking and insane data led to access wrong memory addresses:

            ==16510==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555558fc9cf9 at pc 0x555557aa5d5c bp 0x7fffdc23a530 sp 0x7fffdc23a520
            		 
            READ of size 1 at 0x555558fc9cf9 thread T35
            		 
                #0 0x555557aa5d5b in check_date /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql-common/my_time.c:91
            		 
                #1 0x5555568da41e in Field_temporal_with_date::store_time_dec(st_mysql_time*, unsigned int) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field.cc:5675
            		 
                #2 0x555556918f6a in Field::do_field_temporal(Copy_field*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field_conv.cc:434
            		 
                #3 0x555556916b86 in do_copy_null /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field_conv.cc:245
            		 
                #4 0x555556c286db in unpack_row(rpl_group_info*, TABLE*, unsigned int, unsigned char const*, st_bitmap const*, unsigned char const**, unsigned long*, unsigned char const*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/rpl_record.cc:377
            		 
                #5 0x555556c25bda in Rows_log_event::unpack_current_row(rpl_group_info*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/log_event.h:4601
            		 
                #6 0x555556c1a185 in Rows_log_event::write_row(rpl_group_info*, bool) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17

            Elkin Andrei Elkin added a comment - Here is an ASAN stack as a consequence of losing the original m precision. As noted the original DATETIME(m) field arrives with zero metadata which made it to interpret as DATETIME(0). That caused incorrect unpacking and insane data led to access wrong memory addresses: ==16510==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555558fc9cf9 at pc 0x555557aa5d5c bp 0x7fffdc23a530 sp 0x7fffdc23a520 READ of size 1 at 0x555558fc9cf9 thread T35 #0 0x555557aa5d5b in check_date /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql-common/my_time.c:91 #1 0x5555568da41e in Field_temporal_with_date::store_time_dec(st_mysql_time*, unsigned int) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field.cc:5675 #2 0x555556918f6a in Field::do_field_temporal(Copy_field*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field_conv.cc:434 #3 0x555556916b86 in do_copy_null /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/field_conv.cc:245 #4 0x555556c286db in unpack_row(rpl_group_info*, TABLE*, unsigned int, unsigned char const*, st_bitmap const*, unsigned char const**, unsigned long*, unsigned char const*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/rpl_record.cc:377 #5 0x555556c25bda in Rows_log_event::unpack_current_row(rpl_group_info*) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17098/sql/log_event.h:4601 #6 0x555556c1a185 in Rows_log_event::write_row(rpl_group_info*, bool) /home/andrei/MDB/WTs/10.2/10.2-MDEV-17

            People

              Elkin Andrei Elkin
              Elkin Andrei Elkin
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.