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: | |
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
[11 Nov 2016 16:47]
MySQL Verification Team
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]
MySQL Verification Team
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.