[MDEV-19391] Create new "Registering transaction" thread state Created: 2019-05-04  Updated: 2020-08-25  Resolved: 2019-08-06

Status: Closed
Project: MariaDB Server
Component/s: Locking, Server, Storage Engine - InnoDB, XA
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-20269 Create new "Auditing" thread state Open

 Description   

Currently, when an InnoDB transaction is in the "System lock" state, it appears that it also performs tasks related to transaction registration, since this is done from ha_innobase::external_lock.

Should we create a new thread state called "Registering transaction" or something for this portion of the work?

For example, we can see that the server goes into the "System lock" state and asks the storage engine to get the external lock here:

https://github.com/MariaDB/server/blob/mariadb-10.4.4/sql/lock.cc#L341

And as part of that process, InnoDB calls innobase_register_trx():

https://github.com/MariaDB/server/blob/mariadb-10.4.4/storage/innobase/handler/ha_innodb.cc#L15651

which calls trans_register_ha() and trx_register_for_2pc():

https://github.com/MariaDB/server/blob/mariadb-10.4.4/storage/innobase/handler/ha_innodb.cc#L2987

https://github.com/MariaDB/server/blob/mariadb-10.4.4/sql/handler.cc#L1176

https://github.com/MariaDB/server/blob/mariadb-10.4.4/storage/innobase/handler/ha_innodb.cc#L2779



 Comments   
Comment by Sergei Golubchik [ 2019-08-06 ]

trans_register_ha() and trx_register_for_2pc() are very fast, no locks, just few assignments.
It doesn't make much sense to have a special thread state for that, you'll almost never see a thread in that state.

Comment by Geoff Montee (Inactive) [ 2019-08-06 ]

The reason that I created this task is that I saw threads hanging in this section of code. Since the thread state used in this section of code is "System lock", the user assumed that the hung threads were waiting on some system lock required for the query. I eventually tracked down the root cause to the audit plugin performance issue, MDEV-18661 / MDEV-19291. This occurred due to the call to the mysql_audit_external_lock() function in the handler::ha_external_lock() function:

https://github.com/MariaDB/server/blob/mariadb-10.3.7/sql/handler.cc#L6125

https://github.com/MariaDB/server/blob/mariadb-10.3.7/sql/sql_audit.h#L285

Since the problem ended up being related to the audit plugin API, maybe adding a new thread state like the one in MDEV-20269 would be better.

Generated at Thu Feb 08 08:51:19 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.