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
Nikita Malyavin
added a comment - - edited 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
Bug
Critical
MDEV-16329 Engine-independent online ALTER TABLE
MDEV-28808
Test MDEV-16329 (ALTER ONLINE TABLE) - Core server part
Sergei, please review commits e2f8dff...52f489e, branch bb-10.10-ddl-nikita