1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-07 00:04:31 +03:00
Commit Graph

59 Commits

Author SHA1 Message Date
Marko Mäkelä
1a647b700f MDEV-25487 Assertion failed in lock_rec_move
row_ins_clust_index_entry_low(): Do not enable bulk insert if
any record locks exist on the table. Bulk insert is assumed to
be covered only by an exclusive table lock, with no row-level
locking or undo logging.
2021-04-23 10:07:08 +03:00
Marko Mäkelä
de119fa2b6 MDEV-25297 Assertion: trx->roll_limit <= trx->undo_no in ROLLBACK TO SAVEPOINT
In commit 8ea923f55b (MDEV-24818)
when we optimized multi-statement INSERT transactions into empty tables,
we would roll back the entire transaction on any error. But, we would
fail to invalidate any SAVEPOINT that had been requested in the past.

trx_t::savepoints_discard(): Renamed from trx_roll_savepoints_free().

row_mysql_handle_errors(): If we were in bulk insert, invoke
trx_t::savepoints_discard(). In this way, a future attempt of
ROLLBACK TO SAVEPOINT will return an error.
2021-04-09 09:18:07 +03:00
Marko Mäkelä
1fde581237 MDEV-25315 Crash in SHOW ENGINE INNODB STATUS
In commit 8ea923f55b (MDEV-24818)
when we optimized multi-statement INSERT into an empty table,
we would sometimes wrongly enable bulk insert into a table that
is actually already using row-level locking and undo logging.

trx_has_lock_x(): New predicate, to check if the transaction of
the current thread is holding an exclusive lock on a table.

trx_undo_report_row_operation(): Only invoke
trx_mod_table_time_t::start_bulk_insert() if
trx_has_lock_x() holds.
2021-04-08 18:01:27 +03:00
Marko Mäkelä
8ea923f55b MDEV-24818: Optimize multi-statement INSERT into an empty table
If the user "opts in" (as in the parent
commit 92b2a911e5),
we can optimize multiple INSERT statements to use table-level locking
and undo logging.

There will be a change of behavior:

    CREATE TABLE t(a PRIMARY KEY) ENGINE=InnoDB;
    SET foreign_key_checks=0, unique_checks=0;
    BEGIN; INSERT INTO t SET a=1; INSERT INTO t SET a=1; COMMIT;

will end up with an empty table, because in case of an error,
the entire transaction will be rolled back, instead of rolling
back the failing statement. Previously, the second INSERT statement
would have been logged row by row, and only that second statement
would have been rolled back, leaving the first INSERT intact.

lock_table_x_unlock(), trx_mod_table_time_t::WAS_BULK: Remove.
Because we cannot really support statement rollback in this
optimized mode, we will not optimize the locking. The exclusive
table lock will be held until the end of the transaction.
2021-03-16 15:21:34 +02:00
Marko Mäkelä
92b2a911e5 MDEV-24818 Concurrent use of InnoDB table is impossible until the first transaction is finished
In MDEV-515, we enabled an optimization where an insert into an
empty table will use table-level locking and undo logging.
This may break applications that expect row-level locking.

The SQL statements created by the mysqldump utility will include the
following:

    SET unique_checks=0, foreign_key_checks=0;

We will use these flags to enable the table-level locked and logged
insert. Unless the parameters are set, INSERT will be executed in
the old way, with row-level undo logging and implicit record locks.
2021-03-16 15:20:26 +02:00
Marko Mäkelä
5c9229b96f MDEV-24951 Assertion m.first->second.valid(trx->undo_no) failed
trx_t::commit_in_memory(): Invoke mod_tables.clear().

trx_free_at_shutdown(): Invoke mod_tables.clear() for transactions
that are discarded on shutdown.

Everywhere else, assert mod_tables.empty() on freed transaction objects.
2021-02-24 15:49:58 +02:00
Thirunarayanan Balathandayuthapani
a2fbbba2e3 MDEV-24832 Root page AHI removal fails during rollback of bulk insert
This failure is caused by commit 43ca6059ca
(MDEV-24720). InnoDB fails to remove the ahi entries
during rollback of bulk insert operation. InnoDB should
remove the AHI entries of root page before reinitialising it.

Reviewed-by: Marko Mäkelä
2021-02-10 15:27:25 +05:30
Thirunarayanan Balathandayuthapani
43ca6059ca MDEV-24720 AHI removal during rollback of bulk insert
InnoDB fails to remove the ahi entries during rollback
of bulk insert operation. InnoDB throws the error when
validates the ahi hash tables. InnoDB should remove
the ahi entries while freeing the segment only during
bulk index rollback operation.

Reviewed-by: Marko Mäkelä
2021-02-02 19:24:05 +05:30
Marko Mäkelä
c411393a84 MDEV-24715 Assertion !node->table->skip_alter_undo in CREATE...REPLACE SELECT
In commit 3cef4f8f0f (MDEV-515)
we inadvertently broke CREATE TABLE...REPLACE SELECT statements
by wrongly disabling row-level undo logging.

select_create::prepare(): Only invoke extra(HA_EXTRA_BEGIN_ALTER_COPY)
if no special treatment of duplicates is needed.
2021-01-28 15:26:53 +02:00