Bug #83789 Remove thd_storage_lock_wait from storage engine API
Submitted: 11 Nov 2016 13:29 Modified: 2 Feb 2017 15:18
Reporter: Laurynas Biveinis (OCA) Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Storage Engine API Severity:S3 (Non-critical)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any
Tags: se api

[11 Nov 2016 13:29] Laurynas Biveinis
Description:
Server provides API for storage engine to report back lock wait time: 

void thd_storage_lock_wait(THD *thd, long long value);

Server also provides API for storage engine to indicate that it's waiting on something, including locks (THD_WAIT_ROW_LOCK, THD_WAIT_TABLE_LOCK, THD_WAIT_USER_LOCK):

extern "C" void thd_wait_begin(MYSQL_THD thd, int wait_type);
...
extern "C" void thd_wait_end(MYSQL_THD thd);

It looks like the former interface is fully covered by the latter, resulting in needless duplication in API.

How to repeat:
See above

Suggested fix:
Remove thd_storage_lock_wait, perform its actions (THD::utime_after_lock bump) to thd_wait_begin/thd_wait_end on matching wait types.
[11 Nov 2016 16:47] Sinisa Milivojevic
Hi Laurynas,

To me , it does not look like a duplicate.

The added, new API call reports back a total wait time, while the existing API calls return the status of the particular attribute on the thread. Yes, if you would write some additional code, you could calculate second info from the first two API calls, but it would take some work.

Hence, I do not find it a duplicate.
[14 Nov 2016 10:00] Laurynas Biveinis
In both cases you send the same information to the server, in one the individual waits, in the other their sum, thus it is duplication for the API client (a storage engine). The fact that the implementation of API has to change does not make it less duplicated, and anyway all the implementation change is store timestamp in thd_wait_begin, bump utime_after_lock by (current timestamp - stored timestamp) in thd_wait_end, which is not that hard.
[2 Feb 2017 15:18] Sinisa Milivojevic
Hi Laurynas,

We provide a rich SE API. For some storage engines, the first method is better , while for the other applications the second is better.

What is most important both are used, so both must stay.