|
MDEV-20117.yy is my simplified RQG grammar.
|
There is significant hope that some MTR based brute force replay test could be created.
|
No replay of the problem on 10.3 2019-07.
|
|
The same test running against 10.4 compiled without debug fails frequent with
|
| 2019-07-23 16:40:14 4 [ERROR] InnoDB: Trying to access update undo rec field 45 in index `PRIMARY` of table `test`.`t1` but index has only 8 fields Submit a detailed bug report to https://jira.mariadb.org/. Run also CHECK TABLE `test`.`t1`. n_fields = 3, i = 2
|
| 190723 16:40:14 [ERROR] mysqld got signal 11 ;
|
...
|
# 2019-07-23T16:40:21 [186713] | /home/mleich/work/10.4/bld_fast/sql/mysqld(my_print_stacktrace+0x29)[0x561e199175f9]
|
# 2019-07-23T16:40:21 [186713] | mysys/stacktrace.c:270(my_print_stacktrace)[0x561e193cd2df]
|
# 2019-07-23T16:40:21 [186713] | /lib/x86_64-linux-gnu/libpthread.so.0(+0x11670)[0x7f64e84be670]
|
# 2019-07-23T16:40:21 [186713] | /home/mleich/work/10.4/bld_fast/sql/mysqld(+0xac8f9b)[0x561e1965af9b]
|
# 2019-07-23T16:40:21 [186713] | trx/trx0rec.cc:1790(trx_undo_rec_get_partial_row(unsigned char const*, dict_index_t*, upd_t const*, dtuple_t**, unsigned long, mem_block_info_t*))[0x561e1961a3da]
|
# 2019-07-23T16:40:21 [186713] | row/row0purge.cc:1159(row_purge_parse_undo_rec)[0x561e195d96b1]
|
# 2019-07-23T16:40:21 [186713] | que/que0que.cc:1042(que_thr_step)[0x561e1963c210]
|
# 2019-07-23T16:40:21 [186713] | nptl/pthread_create.c:456(start_thread)[0x7f64e84b46da]
|
# 2019-07-23T16:40:21 [186713] | x86_64/clone.S:107(clone)[0x7f64e7742d7f]
|
|
|
prt == Protocol of my MTR replay test when running against 10.4 compiled with debug
|
MDEV-20117.tgz == Archive with MTR based replay test case
|
|
How to replay the problem:
|
0. Use a Linux
|
1. cd <source>/mysql-test
|
2. tar xvzf MDEV-20117.tgz
|
This unpacks a
|
mysqltest_background.sh
|
main/MDEV-20117.test
|
main/MDEV-20117-master.opt
|
3. cd <tree_with_binaries compiled with debug>/mysql-test
|
4. ./mysql-test-run.pl --mem MDEV-20117
|
|
You might need several MTR runs in order to hit the problem.
|
It could also happen that some other bug (different assert ...) shows up.
|
main/MDEV-20117.test contains partially SQL which might be not strict required for replaying the problem.
|
But its current content seems to improve the likelihood to replay the problem.
|
The main/MDEV-20117-master.opt content might be also not required.
|
But it avoids at least some InnoDB system variable settings which cause
|
sometimes trouble == They cannot be the reason for the current problem.
|
|
Please do not add my replay test case to the regression tests because
|
it consumes too much resources.
|
|
A perfect regression test should use debug_sync or similar.
|
|
|
Simply running provided MTR test case I have the following:
#0 __GI_raise (sig=sig@entry=6) at raise.c:50
|
#1 0x00007ffff7185535 in __GI_abort () at abort.c:79
|
#2 0x00007ffff718540f in __assert_fail_base (fmt=0x7ffff7313588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x179be51 "pos < index->n_def", file=0x179b67e "../storage/innobase/include/dict0dict.ic", line=879, function=<optimized out>) at assert.c:92
|
#3 0x00007ffff7195012 in __GI___assert_fail (assertion=0x179be51 "pos < index->n_def", file=0x179b67e "../storage/innobase/include/dict0dict.ic", line=879, function=0x179be64 "dict_field_t *dict_index_get_nth_field(const dict_index_t *, ulint)") at assert.c:101
|
#4 0x00000000011276cb in dict_index_get_nth_field (index=0x7fff9012e5d8, pos=22) at dict0dict.ic:879
|
#5 0x000000000111facd in dict_index_get_nth_col (index=0x7fff9012e5d8, pos=22) at dict0dict.ic:908
|
#6 0x000000000111ff61 in trx_undo_rec_get_partial_row (ptr=0x2c9a3ce "\004\t@]\021\001", index=0x7fff9012e5d8, update=0x7fffb000b898, row=0x2c99860, ignore_prefix=0, heap=0x2c9a310) at trx0rec.cc:1843
|
#7 0x000000000108b8ea in row_purge_parse_undo_rec (node=0x2c997d8, undo_rec=0x2c9a3a8 "", updated_extern=0x7fffb7ffecc7, thr=0x2c99350) at row0purge.cc:1156
|
#8 0x000000000108a5ea in row_purge (node=0x2c997d8, undo_rec=0x2c9a3a8 "", thr=0x2c99350) at row0purge.cc:1259
|
#9 0x000000000108a49c in row_purge_step (thr=0x2c99350) at row0purge.cc:1321
|
#10 0x0000000000ff67d9 in que_thr_step (thr=0x2c99350) at que0que.cc:1042
|
#11 0x0000000000ff590e in que_run_threads_low (thr=0x2c99350) at que0que.cc:1104
|
#12 0x0000000000ff5678 in que_run_threads (thr=0x2c99350) at que0que.cc:1144
|
#13 0x00000000010dc70f in srv_task_execute () at srv0srv.cc:2462
|
#14 0x00000000010dc4f4 in srv_worker_thread (arg=0x0) at srv0srv.cc:2510
|
#15 0x00007ffff7f86182 in start_thread (arg=<optimized out>) at pthread_create.c:486
|
#16 0x00007ffff727db1f in clone () at clone.S:95
|
|
|
With a similar stack trace I can observe such index/table dis-synchronization:
(gdb) p index->n_def
|
$3 = 8
|
(gdb) p index->table->n_def
|
$4 = 9
|
That was apparently caused by parallel ALTER TABLE:
#0 futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x2c8b7a8) at futex-internal.h:88
|
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x2c8b758, cond=0x2c8b780) at pthread_cond_wait.c:502
|
#2 __pthread_cond_wait (cond=0x2c8b780, mutex=0x2c8b758) at pthread_cond_wait.c:655
|
#3 0x0000000000fbb4f8 in os_event::wait (this=0x2c8b740) at os0event.cc:159
|
#4 0x0000000000fbb053 in os_event::wait_low (this=0x2c8b740, reset_sig_count=327) at os0event.cc:326
|
#5 0x0000000000fbb43d in os_event_wait_low (event=0x2c8b740, reset_sig_count=327) at os0event.cc:515
|
#6 0x00000000010ea642 in sync_array_wait_event (arr=0x2a518d0, cell=@0x7ffff00da470: 0x2a51b80) at sync0arr.cc:469
|
#7 0x00000000010f14a0 in rw_lock_x_lock_wait_func (lock=0x1dc0fe0 <dict_sys+144>, pass=0, threshold=0, file_name=0x18196cf "../storage/innobase/dict/dict0dict.cc", line=5553) at sync0rw.cc:448
|
#8 0x00000000010ef7e0 in rw_lock_x_lock_low (lock=0x1dc0fe0 <dict_sys+144>, pass=0, file_name=0x18196cf "../storage/innobase/dict/dict0dict.cc", line=5553) at sync0rw.cc:503
|
#9 0x00000000010ef295 in rw_lock_x_lock_func (lock=0x1dc0fe0 <dict_sys+144>, pass=0, file_name=0x18196cf "../storage/innobase/dict/dict0dict.cc", line=5553) at sync0rw.cc:662
|
#10 0x000000000106fa4a in dict_sys_t::lock (this=0x1dc0f50 <dict_sys>, file=0x18196cf "../storage/innobase/dict/dict0dict.cc", line=5553) at dict0dict.h:1573
|
#11 0x00000000012384de in dict_index_set_merge_threshold (index=0x7fff8412e658, merge_threshold=50) at dict0dict.cc:5553
|
#12 0x0000000000eac31f in innobase_parse_hint_from_comment (thd=0x7fff74000cf8, table=0x7fff84177ec8, table_share=0x7ffff00de608) at ha_innodb.cc:12179
|
#13 0x0000000000ef1e48 in ha_innobase::commit_inplace_alter_table (this=0x7fff7c045350, altered_table=0x7ffff00dd838, ha_alter_info=0x7ffff00deb88, commit=true) at handler0alter.cc:11370
|
#14 0x0000000000c1699d in handler::ha_commit_inplace_alter_table (this=0x7fff7c045350, altered_table=0x7ffff00dd838, ha_alter_info=0x7ffff00deb88, commit=true) at handler.cc:4575
|
#15 0x000000000096f691 in mysql_inplace_alter_table (thd=0x7fff74000cf8, table_list=0x7fff74011568, table=0x7fff7c03d2c8, altered_table=0x7ffff00dd838, ha_alter_info=0x7ffff00deb88, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7ffff00df2a8, alter_ctx=0x7ffff00df458) at sql_table.cc:7717
|
#16 0x0000000000968a58 in mysql_alter_table (thd=0x7fff74000cf8, new_db=0x7fff740054a8, new_name=0x7fff740058b0, create_info=0x7ffff00e0c58, table_list=0x7fff74011568, alter_info=0x7ffff00e0ba0, order_num=0, order=0x0, ignore=false) at sql_table.cc:10028
|
#17 0x0000000000a16297 in Sql_cmd_alter_table::execute (this=0x7fff74011d40, thd=0x7fff74000cf8) at sql_alter.cc:502
|
#18 0x000000000086ce90 in mysql_execute_command (thd=0x7fff74000cf8) at sql_parse.cc:6098
|
#19 0x0000000000859dea in mysql_parse (thd=0x7fff74000cf8, rawbuf=0x7fff74011460 "ALTER TABLE t1 ADD COLUMN col_int_copy INTEGER", length=46, parser_state=0x7ffff00e6ce8, is_com_multi=false, is_next_command=false) at sql_parse.cc:7908
|
|
|
kevg, for the basic case (table with PRIMARY KEY without column prefix), you should have table->indexes.start->n_def == table->n_def - 1. (The column DB_ROW_ID will not be materialized.) I do not see anything abnormal in your investigation.
When you suspect mismatch, I would suggest to check the column names:
p *index->fields@index->n_fields
|
p *index->table->col_names@100
|
p *index->table->v_col_names@100
|
|
|
After making ALTER TABLE t1 CHANGE COLUMN col_int_copy col_int INTEGER {{ ALGORITHM=COPY}} I got this:
#7 0x0000000000f62aa9 in lock_rec_queue_validate (locked_lock_trx_sys=false, block=0x7fc7ae96d3b0, rec=0x7fc7aeec00a1 "\200", index=0x7fc73802a478, offsets=0x7fc7ae605620) at lock0lock.cc:4963
|
#8 0x0000000000f64afd in lock_clust_rec_read_check_and_lock (flags=0, block=0x7fc7ae96d3b0, rec=0x7fc7aeec00a1 "\200", index=0x7fc73802a478, offsets=0x7fc7ae605620, mode=LOCK_X, gap_mode=0, thr=0x7fc74007e5e0) at lock0lock.cc:5856
|
#9 0x00000000010a9c93 in sel_set_rec_lock (pcur=0x7fc74007e018, rec=0x7fc7aeec00a1 "\200", index=0x7fc73802a478, offsets=0x7fc7ae605620, mode=3, type=0, thr=0x7fc74007e5e0, mtr=0x7fc7ae605948) at row0sel.cc:1262
|
#10 0x00000000010a56f6 in row_search_mvcc (buf=0x7fc740057ec8 "\377", mode=PAGE_CUR_G, prebuilt=0x7fc74007de48, match_mode=0, direction=0) at row0sel.cc:5014
|
#11 0x0000000000ea6721 in ha_innobase::index_read (this=0x7fc74007d4c0, buf=0x7fc740057ec8 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at ha_innodb.cc:9336
|
#12 0x0000000000ea7275 in ha_innobase::index_first (this=0x7fc74007d4c0, buf=0x7fc740057ec8 "\377") at ha_innodb.cc:9710
|
#13 0x0000000000ea74c7 in ha_innobase::rnd_next (this=0x7fc74007d4c0, buf=0x7fc740057ec8 "\377") at ha_innodb.cc:9803
|
#14 0x0000000000c10699 in handler::ha_rnd_next (this=0x7fc74007d4c0, buf=0x7fc740057ec8 "\377") at handler.cc:2834
|
#15 0x0000000000df2833 in rr_sequential (info=0x7fc7ae606d80) at records.cc:477
|
#16 0x000000000079ccd6 in READ_RECORD::read_record (this=0x7fc7ae606d80) at records.h:69
|
#17 0x0000000000e13f5e in mysql_delete (thd=0x7fc740000cf8, table_list=0x7fc740011578, conds=0x7fc7400121f8, order_list=0x7fc7400056a0, limit=18446744073709551615, options=0, result=0x0) at sql_delete.cc:799
|
#18 0x0000000000865e72 in mysql_execute_command (thd=0x7fc740000cf8) at sql_parse.cc:4727
|
#19 0x0000000000859dea in mysql_parse (thd=0x7fc740000cf8, rawbuf=0x7fc740011460 "DELETE FROM t1 WHERE col_int = 6 OR col_int IS NULL", length=51, parser_state=0x7fc7ae60cce8, is_com_multi=false, is_next_command=false) at sql_parse.cc:7908
|
|
|
For the test in MDEV-20117.tgz , I see a few of the following messages before the crash:
diff --git a/storage/innobase/handler/handler0alter.cc b/storage/innobase/handler/handler0alter.cc
|
index 3d8f068b188..4e7c40ee2b9 100644
|
--- a/storage/innobase/handler/handler0alter.cc
|
+++ b/storage/innobase/handler/handler0alter.cc
|
@@ -5903,6 +5903,9 @@ static bool innobase_instant_try(
|
goto func_exit;
|
} else if (page_rec_is_supremum(rec)) {
|
empty_table:
|
+ if (rec_is_alter_metadata(rec, *index)) {
|
+ ib::info() << "emptying after instant DROP";
|
+ }
|
/* The table is empty. */
|
ut_ad(fil_page_index_page_check(block->frame));
|
ut_ad(!page_has_siblings(block->frame));
|
My deterministic test case crashes somewhere else in the debug build (not release build):
--source include/have_innodb.inc
|
|
SET @save_frequency= @@GLOBAL.innodb_purge_rseg_truncate_frequency;
|
SET GLOBAL innodb_purge_rseg_truncate_frequency=1;
|
|
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
|
INSERT INTO t1 VALUES (1);
|
ALTER TABLE t1 ADD COLUMN (b INT, c INT, d INT, e INT NOT NULL DEFAULT 0);
|
ALTER TABLE t1 ADD UNIQUE INDEX(e);
|
|
# Stop purge for a while.
|
connect (purge_control,localhost,root);
|
START TRANSACTION WITH CONSISTENT SNAPSHOT;
|
connection default;
|
|
UPDATE t1 SET b=1;
|
DELETE FROM t1;
|
ALTER TABLE t1 DROP b, DROP c, DROP d, DROP e;
|
|
disconnect purge_control;
|
--source include/wait_all_purged.inc
|
|
SELECT * FROM t1;
|
DROP TABLE t1;
|
SET GLOBAL innodb_purge_rseg_truncate_frequency=@save_frequency;
|
|
10.4 7b4de10477a7bdb51656d827ad2d914d29a4be4c
|
Version: '10.4.8-MariaDB-debug-log' socket: '/dev/shm/10.4d/mysql-test/var/tmp/mysqld.1.sock' port: 16000 Source distribution
|
mysqld: /mariadb/10.4/storage/innobase/include/dict0dict.ic:370: dict_col_t *dict_table_get_nth_col(const dict_table_t *, ulint): Assertion `pos < table->n_def' failed.
|
…
|
#7 0x000055a0e64f112e in dict_table_get_nth_col (table=0x7f81e0176ef8, pos=4) at /mariadb/10.4/storage/innobase/include/dict0dict.ic:370
|
#8 check_col_exists_in_indexes (table=0x7f81e0176ef8, col_no=4, is_v=<optimized out>, only_committed=<optimized out>) at /mariadb/10.4/storage/innobase/handler/handler0alter.cc:8523
|
#9 0x000055a0e64f9295 in commit_cache_norebuild (ha_alter_info=<optimized out>, ctx=<optimized out>, altered_table=<optimized out>, table=<optimized out>, trx=0x7f8230f0d390) at /mariadb/10.4/storage/innobase/handler/handler0alter.cc:10296
|
#10 0x000055a0e64ec8c2 in ha_innobase::commit_inplace_alter_table (this=0x7f81e0177b60, altered_table=0x7f823044cb20, ha_alter_info=0x7f823044c8f8, commit=<optimized out>) at /mariadb/10.4/storage/innobase/handler/handler0alter.cc:11124
|
I think that this issue is caused by MDEV-15562.
If instant DROP COLUMN was never used, we can safely invoke dict_index_t::clear_instant_add() whenever the table becomes empty (even during DML), because that will never reduce the number of fields.
After instant DROP COLUMN, we currently can invoke dict_index_t::clear_instant() if the table turns out to be empty during an ALTER TABLE operation. But, apparently this is unsafe, and we should update the dict_table_t::id and SYS_TABLES.ID in order to hide any pending undo log records from purge.
|
|
Actually, this one is duplicated by MDEV-20479 which is fixed and closed now.
Description: instant drop column could set dict_col_t::ord_part to 0 for an incorrect columns. In a good case like in MDEV-20479 test case this results in an assertion failure. In a bad case this effectively corrupts data dictionary case which then leads to a data corruption which we can observe in a test case for this issue.
|
|
I can still repeat the failure with MDEV-20117.tgz:
|
10.4 18af13b88ba580562981a190c25da128a2e9db26
|
Version: '10.4.8-MariaDB-debug-log' socket: '/dev/shm/10.4/mysql-test/var/tmp/18/mysqld.1.sock' port: 16340 Source distribution
|
2019-09-05 18:31:49 1 [ERROR] InnoDB: Trying to access update undo rec field 53 in index `PRIMARY` of table `test`.`t1` but index has only 8 fields Submit a detailed bug report to https://jira.mariadb.org/. Run also CHECK TABLE `test`.`t1`. n_fields = 3, i = 2
|
mysqld: /mariadb/10.4/storage/innobase/trx/trx0rec.cc:1682: byte *trx_undo_update_rec_get_update(const byte *, dict_index_t *, ulint, trx_id_t, roll_ptr_t, ulint, mem_heap_t *, upd_t **): Assertion `0' failed.
|
…
|
#7 0x0000557718307a9b in trx_undo_update_rec_get_update (ptr=0x55771ab8ccfe "\004\200", index=0x7f186412ed08, type=13, trx_id=53, roll_ptr=2, info_bits=139743404846360, heap=0x55771ab8cc40, upd=0x55771ab8c268) at /mariadb/10.4/storage/innobase/trx/trx0rec.cc:1682
|
#8 0x000055771828a27a in row_purge_parse_undo_rec (node=0x55771ab8c1f0, undo_rec=<optimized out>, updated_extern=<optimized out>, thr=<optimized out>) at /mariadb/10.4/storage/innobase/row/row0purge.cc:1147
|
#9 row_purge (node=0x55771ab8c1f0, undo_rec=<optimized out>, thr=<optimized out>) at /mariadb/10.4/storage/innobase/row/row0purge.cc:1259
|
#10 0x0000557718289121 in row_purge_step (thr=0x55771ab8c138) at /mariadb/10.4/storage/innobase/row/row0purge.cc:1321
|
#11 0x00005577181fe1bb in que_thr_step (thr=<optimized out>) at /mariadb/10.4/storage/innobase/que/que0que.cc:1037
|
#12 que_run_threads_low (thr=0x55771ab8c138) at /mariadb/10.4/storage/innobase/que/que0que.cc:1099
|
#13 que_run_threads (thr=0x55771ab8c138) at /mariadb/10.4/storage/innobase/que/que0que.cc:1139
|
#14 0x00005577182fb900 in trx_purge (n_purge_threads=<optimized out>, truncate=<optimized out>) at /mariadb/10.4/storage/innobase/trx/trx0purge.cc:1316
|
#15 0x00005577182da52f in srv_do_purge (n_total_purged=<optimized out>) at /mariadb/10.4/storage/innobase/srv/srv0srv.cc:2594
|
#16 srv_purge_coordinator_thread (arg=<optimized out>) at /mariadb/10.4/storage/innobase/srv/srv0srv.cc:2720
|
Presumably, at the time of the previous instant ALTER TABLE was executed, the table was empty, and dict_index_t::clear_instant() was invoked. This would cause the crash in purge, if there were any old undo log records of committed transactions waiting for purge. Those old records would become corrupted, because the clustered index would have fewer fields, or the fields could be moved to different positions.
Like I wrote in my previous comment, if we remove rec_is_alter_metadata() information, we must at the same time update SYS_TABLES.ID and dict_table_t::id in order to effectively delete old undo log records for the table. We should try to avoid this rewrite when it is not necessary (say, after removing metadata for instant ADD COLUMN, that is, rec_is_metadata() && !rec_is_alter_metadata()).
My test case was a failed attempt to reproduce the scenario, which should lead you towards the correct direction. It happened to demonstrate an unrelated bug MDEV-20479, which you fixed.
|
|
OK to push
|
|
With the proposed patch, MDEV-20117.tgz still crashed for me.
I think that the proposed patch was removing the wrong code path. The path that it removed was for the case that the table is truly empty, and not even a hidden metadata record exists.
What we must do is to prevent the goto empty_table; when only the metadata record exists, but the metadata record is in the post-10.3 format. We must also adjust page_cur_delete_rec() so that when btr_cur_pessimistic_update() is invoked by innobase_instant_try(), the page type will not be reset:
diff --git a/storage/innobase/handler/handler0alter.cc b/storage/innobase/handler/handler0alter.cc
|
index 14125272daf..ab3ec7ba249 100644
|
--- a/storage/innobase/handler/handler0alter.cc
|
+++ b/storage/innobase/handler/handler0alter.cc
|
@@ -5820,7 +5820,8 @@ static bool innobase_instant_try(
|
dberr_t err = DB_SUCCESS;
|
if (rec_is_metadata(rec, *index)) {
|
ut_ad(page_rec_is_user_rec(rec));
|
- if (!page_has_next(block->frame)
|
+ if (!rec_is_alter_metadata(rec, *index)
|
+ && !page_has_next(block->frame)
|
&& page_rec_is_last(rec, block->frame)) {
|
goto empty_table;
|
}
|
diff --git a/storage/innobase/page/page0cur.cc b/storage/innobase/page/page0cur.cc
|
index ded90c1c4f8..c2bdaee8c13 100644
|
--- a/storage/innobase/page/page0cur.cc
|
+++ b/storage/innobase/page/page0cur.cc
|
@@ -2327,7 +2327,8 @@ page_cur_delete_rec(
|
/* The record must not be the supremum or infimum record. */
|
ut_ad(page_rec_is_user_rec(current_rec));
|
|
- if (page_get_n_recs(page) == 1 && !recv_recovery_is_on()) {
|
+ if (page_get_n_recs(page) == 1 && !recv_recovery_is_on()
|
+ && !rec_is_alter_metadata(current_rec, *index)) {
|
/* Empty the page, unless we are applying the redo log
|
during crash recovery. During normal operation, the
|
page_create_empty() gets logged as one of MLOG_PAGE_CREATE,
|
With this patch, the test in MDEV-20117.tgz runs for me without any issues for the full duration of 5 minutes and 20 seconds.
Writing a test case for this is tricky. I think that I will skip that. If I do not see any test failure from existing tests when omitting the fix of page_cur_delete_rec(), I will write a test case that covers that change. But that test case would not cover the original failure that is demonstrated by MDEV-20117.tgz.
|
|
I tried about an hour with a debugger, but I was unable to create a deterministic test case for the bug.
|
|
kevg found and attempted to fix a different scenario where the bug occurs. In that scenario, the table is empty at the time the very first instant DROP COLUMN is executed. After the operation, purge would process an undo log record for updating a column that no longer exists. This scenario shows that instant DROP/reorder column must always insert or update the metadata record. I pushed a follow-up fix that addresses this scenario.
The scenario of MDEV-20117.tgz is that the table was emptied between instant ALTER TABLE operations. That one I fixed yesterday.
|
MDEV-20117.tgz
prt