Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
Description
--source include/have_debug_sync.inc
|
--source include/have_innodb.inc
|
|
|
create table t1 (a int) engine=InnoDB; |
insert into t1 values (10),(20),(30); |
--send
|
set debug_sync= 'now wait_for downgraded'; |
|
|
--connect (con_alter,localhost,root,,test)
|
set debug_sync= 'alter_table_online_downgraded signal downgraded wait_for goforit'; |
--send
|
alter table t1 add pk int auto_increment primary key, algorithm=copy, lock=none; |
|
|
--connection default
|
--reap
|
delete from t1 where a = 20; |
set debug_sync= 'now signal goforit'; |
|
|
--connection con_alter
|
--reap
|
select * from t1; |
show create table t1; |
|
|
# Cleanup
|
drop table t1; |
set debug_sync= reset; |
ALTER fails with:
|
bb-10.10-MDEV-16329 49ad87590 |
mysqltest: At line 20: query 'reap' failed: ER_KEY_NOT_FOUND (1032): Can't find record in 't1' |
For a side note, in the client the error gets scrambled reliably (at least for me), like this:
MariaDB [test]> alter table t1 add pk int auto_increment primary key, algorithm=copy, lock=none; |
ERROR 1032 (HY000): Can't find record in 't1'e done |
Attachments
Issue Links
- is caused by
-
MDEV-16329 Engine-independent online ALTER TABLE
-
- Closed
-
- relates to
-
MDEV-28808
Test MDEV-16329 (ALTER ONLINE TABLE) - Core server part
-
- Closed
-
Activity
I have updated the branch to 10.11, please see bb-10.11-ddl-nikita [github]
Sergei, in this new branch the commits you have already reviewed:
150f8747 MDEV-29069 follow-up: support partially usable keys
|
bc70105f MDEV-29069 follow-up: allow deterministic DEFAULTs
|
04678329 MDEV-29069 ER_KEY_NOT_FOUND on online autoinc addition + concurrent DELETE
|
New commits for review are c71d8e92...774a0bb9, namely:
55c376fd MDEV-29069 follow-up: improve DEFAULT rules
|
fa07e36b few rgi assertions. this can proof that rgi is always present
|
b97f88f2 MDEV-29069 follow-up optimize find_key
|
de7a5fc8 MDEV-29069 follow-up: fix replication with extra fields + tests
|
c71d8e92 rpl: check should go after defaults and vcols update
|
I have fixed a few bugs here. First, turned out that update_default_fields updates ALL default
fields that have no explicit values, and fields with index < master_columns are not marked for
write, which led to a crash (assertion).
This is fixed in de7a5fc8 fix replication with extra fields + tests, and also few other
post-review things are there, related to master_columns, record_compare() and get_usable_key_parts().
We have discussed with you the optimization to avoid key_parts traversal for each event
(and therefore each find_key() call). I have implemented it in {b97f88f2 optimize find_key}}.
Still I have a feeling that find_key now looks complicated, and I was looking for reasons
to pass RPL_TABLE_LIST directly, and return directly instead of Rpl_table_data.
I have placed a few assertion for rgi presence to prove that it can be safe, but not sure yet.
Finally, i have totally reworked a usability of a key part in{{55c376fd improve DEFAULT rules}}.
It looks complicated now, so here's the idea: it's not enough to have a deterministic default
value, as the underlying fields should also be either explicitly set, or in turn have
deterministic/explicit DEFAULT.
Same, btw, applies to virtual columns, and few tests are included to demonstrate this.
EDIT: Sorry, wrong branch, it's 10.11, not 10.10
Sergei, please review commits e2f8dff...52f489e, branch bb-10.10-ddl-nikita