diff options
| author | Marko Mäkelä <marko.makela@mariadb.com> | 2019-03-20 18:34:49 +0200 |
|---|---|---|
| committer | Marko Mäkelä <marko.makela@mariadb.com> | 2019-03-20 18:34:49 +0200 |
| commit | 630199e7248bce59066850869cf1f932dbf8f994 (patch) | |
| tree | d1322015effa805e62bc73183a1066bf1082fda6 /storage | |
| parent | a77e2668667e46d96c445a4a9a8325b7fe9461b3 (diff) | |
| download | mariadb-git-630199e7248bce59066850869cf1f932dbf8f994.tar.gz | |
MDEV-18981 Possible corruption when using FOREIGN KEY with virtual columns
row_ins_foreign_fill_virtual(): Construct update->old_vrow
with ROW_COPY_DATA instead of ROW_COPY_POINTERS. With the latter,
the object would be pointing to a buffer pool page frame. That page
frame can become stale and invalid as soon as
row_ins_foreign_check_on_constraint() invokes mtr_t::commit().
Most of the time, the pointer target is not going to be overwritten
by anything, and everything appears to work correctly.
Buffer pool page replacement is highly unlikely, and any pessimistic
operation that would overwrite the old location of the record is only
slightly more likely. It is not known whether there is an actual bug.
This came up while diagnosing MDEV-18879 in MariaDB 10.3.
Diffstat (limited to 'storage')
| -rw-r--r-- | storage/innobase/row/row0ins.cc | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/storage/innobase/row/row0ins.cc b/storage/innobase/row/row0ins.cc index 2dc81665a72..da800da1dc3 100644 --- a/storage/innobase/row/row0ins.cc +++ b/storage/innobase/row/row0ins.cc @@ -957,7 +957,7 @@ row_ins_foreign_fill_virtual( upd_field_t* upd_field; dict_vcol_set* v_cols = foreign->v_cols; update->old_vrow = row_build( - ROW_COPY_POINTERS, index, rec, + ROW_COPY_DATA, index, rec, offsets, index->table, NULL, NULL, &ext, cascade->heap); n_diff = update->n_fields; |