mirror of
https://github.com/MariaDB/server.git
synced 2026-10-23 18:49:29 +03:00
60c1218344
at SERIALIZABLE with innodb_snapshot_isolation=ON
Since commit 7fbbbc983f (MDEV-36330), ha_innobase::store_lock() starts
the transaction and opens a read view at the SERIALIZABLE isolation
level when innodb_snapshot_isolation=ON. The transaction is registered
with the server only in ha_innobase::external_lock(), which normally
follows store_lock().
HANDLER OPEN invokes store_lock() through get_lock_data() but never
invokes external_lock(). The transaction started by store_lock() was
therefore never registered with the server, and nothing committed it:
neither the end of the statement nor a subsequent implicit commit. The
next statement on the connection would execute inside that stale
transaction, with its old read view and its READ ONLY attribute.
If the stale transaction was read-only, a subsequent write would be
executed in it without a transaction identifier, and a debug assertion
on trx->id would fail in row_ins_index_entry() or
row_ins_sec_index_entry(). This could happen, for example, when the
session default was READ ONLY and the write was in an explicit
START TRANSACTION READ WRITE, or when ALTER TABLE...ALGORITHM=COPY
copied the rows without undo log.
Changes:
- ha_innobase::store_lock(): Do not start a transaction or open a read
view. Only set the isolation level.
- ha_innobase::external_lock(): At the SERIALIZABLE isolation level with
innodb_snapshot_isolation=ON, start the transaction and open the read
view right before the transaction is registered with
innobase_register_trx(). A transaction that is started here is always
registered with the server. Like before, the read view is created at
the start of the statement, before any rows are accessed.