1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-21 16:03:24 +03:00
Commit Graph

6 Commits

Author SHA1 Message Date
Nirbhay Choubey
8b2e642aa2 MDEV-7635: Update tests to adapt to the new default sql_mode 2017-02-10 06:30:42 -05:00
Sergei Golubchik
f73bdb685d bugfix: UPDATE and virtual BLOBs
When updating a table with virtual BLOB columns, the following might happen:
- an old record is read from the table, it has no virtual blob values
- update_virtual_fields() is run, vcol blob gets its value into the
  record. But only a pointer to the value is in the table->record[0],
  the value is in Field_blob::value String (but it doesn't have to be!
  it can be in the record, if the column is just a copy of another
  columns: ... b VARCHAR, c BLOB AS (b) ...)
- store_record(table,record[1]), old record now is in record[1]
- fill_record() prepares new values in record[0], vcol blob is updated,
  new value replaces the old one in the Field_blob::value
- now both record[1] and record[0] have a pointer that points to the
  *new* vcol blob value. Or record[1] has a pointer to nowhere if
  Field_blob::value had to realloc.

To resolve this we unlink vcol blobs from the pointer to the
data (in the record[1]). Because the value is not *always* in
the Field_blob::value String, we need to remember what blobs
were unlinked. The orphan memory must be freed manually.

To complicate the matter, ha_update_row() is also used in
multi-update, in REPLACE, in INSERT ... ON DUPLICATE KEY UPDATE,
also on REPLACE ... SELECT, REPLACE DELAYED, and LOAD DATA REPLACE, etc
2016-12-12 20:27:38 +01:00
Sergei Golubchik
aebb1038aa bugfix: multi-UPDATE, vcols, const tables
multi-update was setting up read_set/vcol_set in
multi_update::initialize_tables() that is invoked after
the optimizer (JOIN::optimize_inner()). But some rows - if they're from
const tables - will be read already in the optimizer, and these rows
will not have all necessary column/vcol values.

* multi_update::initialize_tables() uses results from the optimizer
  and cannot be moved to be called earlier.
* multi_update::prepare() is called before the optimizer, but
  it cannot set up read_set/vcol_set, because the optimizer
  might reset them (see SELECT_LEX::update_used_tables()).

As a fix I've added a new method, select_result::prepare_to_read_rows(),
it's called from inside the optimizer just before make_join_statistics().
2016-12-12 20:27:38 +01:00
Sergei Golubchik
b8f51c04d3 bugfix: update-behind-insert
sql_insert.cc calls handler->ha_update_row() for
REPLACE and INSERT... ON DUPLICATE KEY UPDATE
2016-12-12 20:27:37 +01:00
Sergei Golubchik
b38ff28ade bugfix: mark_columns_needed_for_update
cannot use TABLE:merge_keys for that, because Field::part_of_key
was designed to mark fields for KEY_READ, so a field is not a
"part of key", if only prefix of the field is.
2016-12-12 20:27:36 +01:00
Sergei Golubchik
8b6c0542db bugfix: stored column depends on virtual depends on updated
TABLE::mark_virtual_col() was polluting table->vcol_set
and that confused the following mark_virtual_col()
2016-12-12 20:27:32 +01:00