Hi Serg!, Thanks for the review On Wed, Aug 21, 2019 at 2:03 AM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Sachin!
On Aug 20, Sachin Setiya wrote:
revision-id: c776ed4d6ec (mariadb-10.4.5-153-gc776ed4d6ec) parent(s): 4ca016237f1 author: Sachin <sachin.setiya@mariadb.com> committer: Sachin <sachin.setiya@mariadb.com> timestamp: 2019-07-30 03:42:21 +0530 message:
MDEV-19848 Server crashes in check_vcol_forward_refs upon INSERT DELAYED into table with long blob key
There are 2 issues
1st:- in make_new_field when we & into new field flag we forget LONG_UNIQUE_HASH_FIELD Flag.
2nd:- We are calling parse_vcol_defs on keyinfo , but they are not in right form. We should call setup_keyinfo_hash_all before calling parse_vcol_defs
This looks quite suspicious.
Ideally, Delayed_insert::get_local_table() should just create a copy of the table, but not modify the original table. In your case it constantly modifies KEY's of the original table. It's kind of dirty.
Agree , To solve this I created a new key_info copy for delayed_local table.
As for the real bug, see what parse_vcol_defs() is doing for long unique fields. In particular, it sets
keypart->field->vcol_info= table->field[keypart->field->field_index]->vcol_info;
To solve this I added a if condition + if (!keypart->field->vcol_info || + !keypart->field->vcol_info->expr) Although it is still dirty , I was unable to come up with better solution. Please let me know if I can solve it using some other way.
but the keypart here is in the original Delayed_insert::table, while field and vcol_info is in a copy (created in Delayed_insert::get_local_table). This seems to be just wrong.
I'd really prefer Delayed_insert::get_local_table to not change anything in the Delayed_insert::table.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Patch link http://lists.askmonty.org/pipermail/commits/2019-October/014029.html Buildbot bb-10.4-sachin -- Regards Sachin Setiya Software Engineer at MariaDB