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

InnoDB fails to apply the redo log to page_compressed tablespace

Details

    Description

      Alter table rebuild fails when it fails to read the externally stored colum
      for the compressed tablespace. Before alter operation, InnoDB just started
      after crash recovery. This could lead some issue in crash recovery.

      While analysing the recovery, InnoDB fails to apply the redo log for compressed tablespace.
      The reason is that InnoDB assumes that pages has been freed while applying
      the redo log for it. Problematic page has been freed and reinitialize multiple
      times. InnoDB needs to do multiple scan due to small buffer pool size.
      InnoDB stores the freed page information only when we don't run out
      of buffer pool. But InnoDB assigns the freed page ranges even though
      we don't have complete freed range information.

      This issue should persist from 10.5 onwards.

      Crash happens due to skip of redo log apply:

      #3  0x00007ffff7842476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
      #4  0x00007ffff78287f3 in __GI_abort () at ./stdlib/abort.c:79
      #5  0x0000555556a600b9 in ut_dbg_assertion_failed (expr=0x5555572ef4a9 "buf != field_ref_zero", 
          file=0x5555572eef38 "/home/thiru/mariadb_parent/server/11.0/storage/innobase/row/row0merge.cc", line=781)
          at /home/thiru/mariadb_parent/server/11.0/storage/innobase/ut/ut0dbg.cc:60
      #6  0x000055555698586d in row_merge_buf_add (buf=0x7fffa001f638, fts_index=0x0, old_table=0x5555588e7df8, new_table=0x7fffa002f798, 
          psort_info=0x0, row=0x7fffa00ae778, ext=0x7fffa00ae888, doc_id=0x7ffff40745a8, conv_heap=0x0, err=0x7ffff4074590, 
          v_heap=0x7ffff40745a0, my_table=0x7ffff4075dc0, trx=0x7ffff4bc7b80, col_collate=0x0)
          at /home/thiru/mariadb_parent/server/11.0/storage/innobase/row/row0merge.cc:781
      #7  0x000055555698d19f in row_merge_read_clustered_index (trx=0x7ffff4bc7b80, table=0x7ffff4075dc0, old_table=0x5555588e7df8, 
          new_table=0x7fffa002f798, online=true, index=0x7fffa002f4d8, fts_sort_idx=0x0, psort_info=0x0, files=0x7fffa00315b8, 
          key_numbers=0x7fffa002f4e0, n_index=1, defaults=0x0, add_v=0x0, col_map=0x7fffa002f640, add_autoinc=18446744073709551615, sequence=..., 
          block=0x7fffe0149000 "", skip_pk_sort=true, tmpfd=0x7ffff4074ef0, stage=0x7fffa0025498, pct_cost=50, crypt_block=0x0, 
          eval_table=0x7ffff4075dc0, allow_not_null=false, col_collate=0x0)
          at /home/thiru/mariadb_parent/server/11.0/storage/innobase/row/row0merge.cc:2567
      #8  0x0000555556994cc8 in row_merge_build_indexes (trx=0x7ffff4bc7b80, old_table=0x5555588e7df8, new_table=0x7fffa002f798, online=true, 
          indexes=0x7fffa002f4d8, key_numbers=0x7fffa002f4e0, n_indexes=1, table=0x7ffff4075dc0, defaults=0x0, col_map=0x7fffa002f640, 
          add_autoinc=18446744073709551615, sequence=..., skip_pk_sort=true, stage=0x7fffa0025498, add_v=0x0, eval_table=0x7ffff4075dc0, 
          allow_not_null=false, col_collate=0x0) at /home/thiru/mariadb_parent/server/11.0/storage/innobase/row/row0merge.cc:4777
      #9  0x000055555682a4c4 in ha_innobase::inplace_alter_table (this=0x7fffa001d4f0, altered_table=0x7ffff4075dc0, ha_alter_info=0x7ffff4075d00)
          at /home/thiru/mariadb_parent/server/11.0/storage/innobase/handler/handler0alter.cc:8827
      #10 0x00005555560ee9c1 in handler::ha_inplace_alter_table (this=0x7fffa001d4f0, altered_table=0x7ffff4075dc0, ha_alter_info=0x7ffff4075d00)
          at /home/thiru/mariadb_parent/server/11.0/sql/handler.h:4879
      #11 0x00005555560ddab1 in mysql_inplace_alter_table (thd=0x7fffa0000d58, table_list=0x7fffa0013570, table=0x7fffa001a148, 
          altered_table=0x7ffff4075dc0, ha_alter_info=0x7ffff4075d00, target_mdl_request=0x7ffff4076620, ddl_log_state=0x7ffff4075ca0, 
          trigger_param=0x7ffff40761c0, alter_ctx=0x7ffff4077250, partial_alter=@0x7ffff4075ba6: false, start_alter_id=@0x7ffff4075be0: 0, 
          if_exists=false) at /home/thiru/mariadb_parent/server/11.0/sql/sql_table.cc:7871
      #12 0x00005555560e7d58 in mysql_alter_table (thd=0x7fffa0000d58, new_db=0x7fffa0005ad0, new_name=0x7fffa0005f30, 
          create_info=0x7ffff4078100, table_list=0x7fffa0013570, recreate_info=0x7ffff4077f50, alter_info=0x7ffff4077f90, order_num=0, order=0x0, 
          ignore=false, if_exists=false) at /home/thiru/mariadb_parent/server/11.0/sql/sql_table.cc:11076
      #13 0x00005555561a4f88 in Sql_cmd_alter_table::execute (this=0x7fffa0013c88, thd=0x7fffa0000d58)
          at /home/thiru/mariadb_parent/server/11.0/sql/sql_alter.cc:688
      #14 0x0000555555fb8543 in mysql_execute_command (thd=0x7fffa0000d58, is_called_from_prepared_stmt=false)
          at /home/thiru/mariadb_parent/server/11.0/sql/sql_parse.cc:6125
      --Type <RET> for more, q to quit, c to continue without paging--
      #15 0x0000555555fbe5b8 in mysql_parse (thd=0x7fffa0000d58, rawbuf=0x7fffa0013490 "alter table test.t6 force", length=25, 
          parser_state=0x7ffff40792b0) at /home/thiru/mariadb_parent/server/11.0/sql/sql_parse.cc:8123
      #16 0x0000555555faa4cd in dispatch_command (command=COM_QUERY, thd=0x7fffa0000d58, packet=0x7fffa000b159 "alter table test.t6 force", 
          packet_length=25, blocking=true) at /home/thiru/mariadb_parent/server/11.0/sql/sql_parse.cc:1894
      #17 0x0000555555fa8e83 in do_command (thd=0x7fffa0000d58, blocking=true) at /home/thiru/mariadb_parent/server/11.0/sql/sql_parse.cc:1407
      #18 0x0000555556198fb5 in do_handle_one_connection (connect=0x555558b78608, put_in_cache=true)
          at /home/thiru/mariadb_parent/server/11.0/sql/sql_connect.cc:1415
      #19 0x0000555556198d16 in handle_one_connection (arg=0x555558b78608) at /home/thiru/mariadb_parent/server/11.0/sql/sql_connect.cc:1317
      #20 0x00005555566eea67 in pfs_spawn_thread (arg=0x555558ad6f48) at /home/thiru/mariadb_parent/server/11.0/storage/perfschema/pfs.cc:2201
      #21 0x00007ffff7894ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
      #22 0x00007ffff7926a40 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
      

      Attachments

        1. CR-2098.yy
          0.6 kB
        2. CR-2098--MDEV-34156.cfg
          47 kB
        3. data_1.tar.gz
          2.54 MB
        4. encryption_keys.txt
          0.4 kB

        Issue Links

          Activity

            The test appears to be timing sensitive. I am only able to get a multi-batch recovery if I start with a larger innodb_buffer_pool_size and a large enough innodb_log_file_size and then on the kill+restart specify the minimum innodb_buffer_pool_size=5M. But I fail to reproduce the failure.

            marko Marko Mäkelä added a comment - The test appears to be timing sensitive. I am only able to get a multi-batch recovery if I start with a larger innodb_buffer_pool_size and a large enough innodb_log_file_size and then on the kill+restart specify the minimum innodb_buffer_pool_size=5M . But I fail to reproduce the failure.

            I am able to reproduce the bug with the following modification to the above test:

            @@ -2,6 +2,7 @@
             --source include/have_sequence.inc
             --source include/have_debug.inc
             --source include/not_embedded.inc
            +call mtr.add_suppression("InnoDB: Crash recovery is broken");
             create table t1(f1 int not null, f2 text)engine=innodb;
             create table t2(f1 int not null, f2 text)engine=innodb;
             let $shutdown_timeout=;
            @@ -11,8 +12,8 @@
             insert into t1 select seq, repeat('b', 8000) from seq_1_to_128;
             insert into t2 select seq, repeat('a', 8000) from seq_1_to_6;
             delete from t2;
            ---source include/wait_all_purged.inc
            -insert into t1 select seq, repeat('b', 8000) from seq_1_to_512;
            +set global innodb_max_purge_lag_wait=0;
            +insert into t1 select seq, repeat('b', 8000) from seq_1_to_1024;
             insert into t2 select seq, repeat('a', 8000) from seq_1_to_32;
             let $restart_parameters=;
             let $shutdown_timeout=0;
            

            This revealed another bug on my system, and I can also reproduce that in ./mtr --rr:

            10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3

            2024-06-05 13:46:15 0 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9826481.
            2024-06-05 13:46:15 0 [Note] InnoDB: To recover: 111 pages
            2024-06-05 13:46:15 0 [Note] InnoDB: 128 rollback segments are active.
            2024-06-05 13:46:15 0 [Note] InnoDB: Crash recovery was broken between LSN=9826481 and checkpoint LSN=8152818.
            

            I think that we will need the following safety fix to prevent us from doing exactly the opposite of our intention:

            diff --git a/storage/innobase/log/log0recv.cc b/storage/innobase/log/log0recv.cc
            index 6b6a686823c..52ad0306d90 100644
            --- a/storage/innobase/log/log0recv.cc
            +++ b/storage/innobase/log/log0recv.cc
            @@ -4728,7 +4728,9 @@ dberr_t recv_recovery_from_checkpoint_start()
             		}
             		log_sys.set_buf_free(recv_sys.offset);
             		if (recv_needed_recovery
            -	            && srv_operation <= SRV_OPERATION_EXPORT_RESTORED) {
            +	            && srv_operation <= SRV_OPERATION_EXPORT_RESTORED
            +		    && recv_sys.lsn - log_sys.last_checkpoint_lsn
            +		    < log_sys.log_capacity) {
             			/* Write a FILE_CHECKPOINT marker as the first thing,
             			before generating any other redo log. This ensures
             			that subsequent crash recovery will be possible even
            

            However, even with this fix, fil_names_clear() would be invoked as part of log_checkpoint() and it would momentarily make the log un-recoverable. Please file a separate bug (against the earliest supported version 10.5) for applying the above fix. Hopefully you can find a more reliable way of reproducing it.

            I also reproduced the interesting part that the test was supposed to demonstrate:

            10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3

            mysqltest: At line 22: query 'alter table t2 force' failed: ER_GET_ERRNO (1030): Got error 106 "Transport endpoint is already connected" from storage engine InnoDB
            

            If I additionally apply the patch that exactly reverts MDEV-31803, the test will pass, with two errors about the broken crash recovery (due to the disabled log checkpoints and the too small log file):

            2024-06-05 14:04:29 3 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9494710.
            [the server is killed and restarted]
            2024-06-05 14:04:31 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=63493
            2024-06-05 14:04:31 0 [Note] InnoDB: Multi-batch recovery needed at LSN 2102297
            2024-06-05 14:04:31 0 [Note] InnoDB: End of log at LSN=9827918
            2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 2102297/9827918; 140 pages
            2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 4116888/9827918; 130 pages
            2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 6131687/9827918; 130 pages
            2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 8146297/9827918; 130 pages
            2024-06-05 14:04:31 0 [Note] InnoDB: To recover: 111 pages
            2024-06-05 14:04:31 0 [Note] InnoDB: 128 rollback segments are active.
            2024-06-05 14:04:31 0 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9828036.
            2024-06-05 14:04:31 0 [Note] InnoDB: Crash recovery was broken between LSN=9828036 and checkpoint LSN=8146297.
            

            This is a good starting point for testing a revised fix that is not an exact revert of MDEV-31803.

            marko Marko Mäkelä added a comment - I am able to reproduce the bug with the following modification to the above test: @@ -2,6 +2,7 @@ --source include/have_sequence.inc --source include/have_debug.inc --source include/not_embedded.inc +call mtr.add_suppression("InnoDB: Crash recovery is broken"); create table t1(f1 int not null, f2 text)engine=innodb; create table t2(f1 int not null, f2 text)engine=innodb; let $shutdown_timeout=; @@ -11,8 +12,8 @@ insert into t1 select seq, repeat('b', 8000) from seq_1_to_128; insert into t2 select seq, repeat('a', 8000) from seq_1_to_6; delete from t2; ---source include/wait_all_purged.inc -insert into t1 select seq, repeat('b', 8000) from seq_1_to_512; +set global innodb_max_purge_lag_wait=0; +insert into t1 select seq, repeat('b', 8000) from seq_1_to_1024; insert into t2 select seq, repeat('a', 8000) from seq_1_to_32; let $restart_parameters=; let $shutdown_timeout=0; This revealed another bug on my system, and I can also reproduce that in ./mtr --rr : 10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3 2024-06-05 13:46:15 0 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9826481. 2024-06-05 13:46:15 0 [Note] InnoDB: To recover: 111 pages 2024-06-05 13:46:15 0 [Note] InnoDB: 128 rollback segments are active. 2024-06-05 13:46:15 0 [Note] InnoDB: Crash recovery was broken between LSN=9826481 and checkpoint LSN=8152818. I think that we will need the following safety fix to prevent us from doing exactly the opposite of our intention: diff --git a/storage/innobase/log/log0recv.cc b/storage/innobase/log/log0recv.cc index 6b6a686823c..52ad0306d90 100644 --- a/storage/innobase/log/log0recv.cc +++ b/storage/innobase/log/log0recv.cc @@ -4728,7 +4728,9 @@ dberr_t recv_recovery_from_checkpoint_start() } log_sys.set_buf_free(recv_sys.offset); if (recv_needed_recovery - && srv_operation <= SRV_OPERATION_EXPORT_RESTORED) { + && srv_operation <= SRV_OPERATION_EXPORT_RESTORED + && recv_sys.lsn - log_sys.last_checkpoint_lsn + < log_sys.log_capacity) { /* Write a FILE_CHECKPOINT marker as the first thing, before generating any other redo log. This ensures that subsequent crash recovery will be possible even However, even with this fix, fil_names_clear() would be invoked as part of log_checkpoint() and it would momentarily make the log un-recoverable. Please file a separate bug (against the earliest supported version 10.5) for applying the above fix. Hopefully you can find a more reliable way of reproducing it. I also reproduced the interesting part that the test was supposed to demonstrate: 10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3 mysqltest: At line 22: query 'alter table t2 force' failed: ER_GET_ERRNO (1030): Got error 106 "Transport endpoint is already connected" from storage engine InnoDB If I additionally apply the patch that exactly reverts MDEV-31803 , the test will pass, with two errors about the broken crash recovery (due to the disabled log checkpoints and the too small log file): 2024-06-05 14:04:29 3 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9494710. [the server is killed and restarted] 2024-06-05 14:04:31 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=63493 2024-06-05 14:04:31 0 [Note] InnoDB: Multi-batch recovery needed at LSN 2102297 2024-06-05 14:04:31 0 [Note] InnoDB: End of log at LSN=9827918 2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 2102297/9827918; 140 pages 2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 4116888/9827918; 130 pages 2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 6131687/9827918; 130 pages 2024-06-05 14:04:31 0 [Note] InnoDB: To recover: LSN 8146297/9827918; 130 pages 2024-06-05 14:04:31 0 [Note] InnoDB: To recover: 111 pages 2024-06-05 14:04:31 0 [Note] InnoDB: 128 rollback segments are active. 2024-06-05 14:04:31 0 [ERROR] InnoDB: Crash recovery is broken due to insufficient innodb_log_file_size; last checkpoint LSN=63493, current LSN=9828036. 2024-06-05 14:04:31 0 [Note] InnoDB: Crash recovery was broken between LSN=9828036 and checkpoint LSN=8146297. This is a good starting point for testing a revised fix that is not an exact revert of MDEV-31803 .

            Without MDEV-31803 patch, the following test case will fail:

            --source include/have_debug.inc
            --source include/have_innodb.inc
            --source include/have_sequence.inc
             
            let $basedir=$MYSQLTEST_VARDIR/tmp/backup;
            let MYSQLD_DATADIR=`select @@datadir`;
             
            CREATE TABLE t1(f1 text, index idx(f1(20))) ENGINE INNODB;
             
            # No checkpoint happens during this restart
             
            let $shutdown_timeout=;
            set global innodb_fast_shutdown=0;
            let $restart_paramters=--debug_dbug=+d,ib_log_checkpoint_avoid_hard --innodb_flush_sync=0;
            --source include/restart_mysqld.inc
            set global debug_dbug="+d,ib_log_checkpoint_avoid_hard";
             
            --disable_result_log
            exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf  --backup --target-dir=$basedir;
            --enable_result_log
             
            INSERT INTO t1 SELECT repeat('a', 8000) FROM seq_1_to_1280;
            DELETE FROM t1;
            SET GLOBAL innodb_max_purge_lag_wait=0;
            INSERT INTO t1 VALUES('a');
             
            --echo # XTRABACKUP PREPARE
            exec $XTRABACKUP --prepare --target-dir=$basedir;
             
            let $shutdown_timeout=0;
            --source include/shutdown_mysqld.inc
             
            # Since there is no checkpoint during previous run, we can
            # Copy the datafile from t1.ibd and start the server
             
            remove_file $MYSQLD_DATADIR/test/t1.ibd;
            copy_file $basedir/test/t1.ibd $MYSQLD_DATADIR/test/t1.ibd;
            --enable_result_log
            --source include/start_mysqld.inc
             
            SELECT COUNT(*) FROM t1;
            ALTER TABLE t1 FORCE;
            DROP TABLE t1;
            

            .opt file for the above test case:

            --innodb_doublewrite=0
            --innodb_log_file_size=1G
            --innodb_immediate_scrub_data_uncompressed=1
            

            Failure:

            2024-06-10 13:42:54 0 [ERROR] [FATAL] InnoDB: Trying to write 16384 bytes at 10485760 outside the bounds of the file: ./test/t1.ibd
            stdlib/abort.c:81(__GI_abort)[0x7f158ee287f3]
            fil/fil0fil.cc:2721(fil_invalid_page_access_msg(char const*, unsigned long, unsigned long, bool))[0x555a7d442d7f]
            fil/fil0fil.cc:2796(fil_space_t::io(IORequest const&, unsigned long, unsigned long, void*, buf_page_t*))[0x555a7d4434b2]
            buf/buf0flu.cc:993(fil_space_t::flush_freed(bool))[0x555a7d3cb192]
            buf/buf0flu.cc:1176(buf_flush_space(unsigned int))[0x555a7d3cbfd5]
            buf/buf0flu.cc:1460(buf_do_flush_list_batch(unsigned long, unsigned long))[0x555a7d3cd338]
            buf/buf0flu.cc:1560(buf_flush_list_holding_mutex(unsigned long, unsigned long))[0x555a7d3cda8d]
            buf/buf0flu.cc:1586(buf_flush_list(unsigned long, unsigned long))[0x555a7d3cdc6a]
            buf/buf0flu.cc:2140(buf_flush_sync_for_checkpoint(unsigned long))[0x555a7d3cf3c3]
            buf/buf0flu.cc:2412(buf_flush_page_cleaner())[0x555a7d3d0850]
            

            thiru Thirunarayanan Balathandayuthapani added a comment - Without MDEV-31803 patch, the following test case will fail: --source include/have_debug.inc --source include/have_innodb.inc --source include/have_sequence.inc   let $basedir=$MYSQLTEST_VARDIR/tmp/backup; let MYSQLD_DATADIR=`select @@datadir`;   CREATE TABLE t1(f1 text, index idx(f1(20))) ENGINE INNODB;   # No checkpoint happens during this restart   let $shutdown_timeout=; set global innodb_fast_shutdown=0; let $restart_paramters=--debug_dbug=+d,ib_log_checkpoint_avoid_hard --innodb_flush_sync=0; --source include/restart_mysqld.inc set global debug_dbug="+d,ib_log_checkpoint_avoid_hard";   --disable_result_log exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$basedir; --enable_result_log   INSERT INTO t1 SELECT repeat('a', 8000) FROM seq_1_to_1280; DELETE FROM t1; SET GLOBAL innodb_max_purge_lag_wait=0; INSERT INTO t1 VALUES('a');   --echo # XTRABACKUP PREPARE exec $XTRABACKUP --prepare --target-dir=$basedir;   let $shutdown_timeout=0; --source include/shutdown_mysqld.inc   # Since there is no checkpoint during previous run, we can # Copy the datafile from t1.ibd and start the server   remove_file $MYSQLD_DATADIR/test/t1.ibd; copy_file $basedir/test/t1.ibd $MYSQLD_DATADIR/test/t1.ibd; --enable_result_log --source include/start_mysqld.inc   SELECT COUNT(*) FROM t1; ALTER TABLE t1 FORCE; DROP TABLE t1; .opt file for the above test case: --innodb_doublewrite=0 --innodb_log_file_size=1G --innodb_immediate_scrub_data_uncompressed=1 Failure: 2024-06-10 13:42:54 0 [ERROR] [FATAL] InnoDB: Trying to write 16384 bytes at 10485760 outside the bounds of the file: ./test/t1.ibd stdlib/abort.c:81(__GI_abort)[0x7f158ee287f3] fil/fil0fil.cc:2721(fil_invalid_page_access_msg(char const*, unsigned long, unsigned long, bool))[0x555a7d442d7f] fil/fil0fil.cc:2796(fil_space_t::io(IORequest const&, unsigned long, unsigned long, void*, buf_page_t*))[0x555a7d4434b2] buf/buf0flu.cc:993(fil_space_t::flush_freed(bool))[0x555a7d3cb192] buf/buf0flu.cc:1176(buf_flush_space(unsigned int))[0x555a7d3cbfd5] buf/buf0flu.cc:1460(buf_do_flush_list_batch(unsigned long, unsigned long))[0x555a7d3cd338] buf/buf0flu.cc:1560(buf_flush_list_holding_mutex(unsigned long, unsigned long))[0x555a7d3cda8d] buf/buf0flu.cc:1586(buf_flush_list(unsigned long, unsigned long))[0x555a7d3cdc6a] buf/buf0flu.cc:2140(buf_flush_sync_for_checkpoint(unsigned long))[0x555a7d3cf3c3] buf/buf0flu.cc:2412(buf_flush_page_cleaner())[0x555a7d3d0850]

            Thank you, I can reproduce that crash on 10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3 if I revert the MDEV-31803 fix. If the revised patch of this bug passes both tests, we should be good to go.

            marko Marko Mäkelä added a comment - Thank you, I can reproduce that crash on 10.11 1bf0950b191aaaa181068551fa241c9d09e6c7c3 if I revert the MDEV-31803 fix. If the revised patch of this bug passes both tests, we should be good to go.

            I see that the fix is removing an incorrect condition that had been added in MDEV-29911 (not in the 10.6 version of that).

            marko Marko Mäkelä added a comment - I see that the fix is removing an incorrect condition that had been added in MDEV-29911 (not in the 10.6 version of that).

            People

              thiru Thirunarayanan Balathandayuthapani
              thiru Thirunarayanan Balathandayuthapani
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.