1
0
mirror of https://github.com/MariaDB/server.git synced 2025-11-28 17:36:30 +03:00
Commit Graph

4 Commits

Author SHA1 Message Date
Marko Mäkelä
5c3ff5cb93 Merge 10.3 into 10.4 2019-04-02 11:04:54 +03:00
Marko Mäkelä
1e9c2b2305 Merge 10.1 into 10.2 2019-03-27 12:26:11 +02:00
Monty
7fb9d64989 Changed FLUSH TABLES to not change share version
Part of MDEV-5336 Implement LOCK FOR BACKUP

Originally both table metadata lock and global read lock protection
were acquired before getting TABLE from table cache. This will be
reordered in a future commit with MDL_BACKUP_XXX locks so that we
first take table metadata lock, then get TABLE from table cache, then
acquire analogue of global read lock.

This patch both simplifies FLUSH TABLES code, makes FLUSH TABLES to
lock less and also enables FLUSH TABLES code to be used with backup
locks.

The usage of FLUSH TABLES changes slightly:
- FLUSH TABLES without any arguments will now only close not used tables
  and tables locked by the FLUSH TABLES connection.  All not used table
  shares will be closed.
  Tables locked by the FLUSH TABLES connection will be reopened and
  re-locked after all others has stoped using the table (as before).
  If there was no locked tables, then FLUSH TABLES is instant and will
  not cause any waits.
  FLUSH TABLES will not wait for any in use table.
- FLUSH TABLES with a table list, will ensure that the tables are closed
  before statement returns. The code is now only using MDL locks and not
  table share versions, which simplices the code greatly. One visible
  change is that the server will wait for the end of the transaction that
  are using the tables. Before FLUSH TABLES only waited for the statements
  to end.

Signed-off-by: Monty <monty@mariadb.org>
2018-12-09 22:12:26 +02:00
Monty
4cd2a0eb56 MDEV-15243 Crash with virtual fields and row based binary logging
The cause of this was several different bugs:

- When using binary logging with binlog_row_image=FULL
  the all bits in read_set was set, which caused a
  different (wrong) pattern for marking vcol_set.
- TABLE::mark_virtual_columns_for_write() didn't in all
  cases mark vcol_set with the vcol_field.
- TABLE::update_virtual_fields() has to update all
  vcol fields on REPLACE if binary logging with FULL
  is used.
- VCOL_UPDATE_INDEXED should update all vcol fields part
  of an index that was not updated by VCOL_UPDATE_FOR_READ
- max_row_length() calculated length of NULL and not
  used fields. This didn't cause any crash, but used
  more memory than needed.
2018-05-24 18:55:12 +03:00