FB8-104: enabling subsecond lock_wait_timeout #980
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
percona-ysorokin
suggested changes
Mar 5, 2019
sql/auth/sql_auth_cache.cc
Outdated
| @@ -3475,6 +3475,8 @@ void shutdown_acl_cache() { | |||
|
|
|||
| /* Constants used by Acl_cache_lock_guard */ | |||
| static const ulong ACL_CACHE_LOCK_TIMEOUT = 3600UL; | |||
| static const ulong ACL_CACHE_LOCK_TIMEOUT_NSEC = | |||
There was a problem hiding this comment.
ulong is not guaranteed to be 64-bit, and therefore may be truncated here as ACL_CACHE_LOCK_TIMEOUT * 1000000000ULL >2^32
Suggested change
| static const ulong ACL_CACHE_LOCK_TIMEOUT_NSEC = | |
| static constexpr ulonglong ACL_CACHE_LOCK_TIMEOUT_NSEC = |
There was a problem hiding this comment.
Thanks, this was one of the typos. I found another when rereading my changes, looks like there aren't any timeout errors so far with these changes.
Updated, and I'll do another update tomorrow with the test changes.
| "precision.", | ||
| // very small nanosecond values will effectively be no waiting | ||
| HINT_UPDATEABLE SESSION_VAR(lock_wait_timeout_double), | ||
| CMD_LINE(REQUIRED_ARG), VALID_RANGE(0, LONG_TIMEOUT), DEFAULT(LONG_TIMEOUT), |
There was a problem hiding this comment.
Is 0 a valid value now on purpose?
There was a problem hiding this comment.
Yes, to allow values below 1 second.
|
Updated with changed tests. |
dutow
changed the title
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
hermanlee
requested changes
Mar 12, 2019
There was a problem hiding this comment.
I'm seeing a number of test failures due to loading of locking_service.so.
CURRENT_TEST: main.locking_service
mysqltest: At line 34: Query 'CREATE FUNCTION service_get_read_locks RETURNS INT SONAME "$LOCKING_SERVICE"' failed.
ERROR 1126 (HY000): Can't open shared library 'locking_service.so' (errno: 0 /data/users/herman/rocks-mysql/8.0/build-8.0-Debug/plugin_output_directory/locking
service.so: undefined symbol: _Z29acquire_lo)
I think some of the plugins and gunit tests need to change acquire_locking_service_locks to acquire_locking_service_locks_nsec?
| You should have received a copy of the GNU General Public License | ||
| along with this program; if not, write to the Free Software | ||
| Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ | ||
| This program is free software; you can redistribute it and/or modify |
There was a problem hiding this comment.
Could this indent change be reverted and the original indent spacing be preserved?
|
@dutow has updated the pull request. Re-import the pull request |
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
hermanlee
force-pushed
the
fb-mysql-8.0.13
branch
from
e9926c3 to
c3bd1c6
Compare
hermanlee
approved these changes
Mar 21, 2019
Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: c21adb7 -------- c21adb7 -------- Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT @global.lock_wait_timeout; @global.lock_wait_timeout 604800.000000
|
@dutow has updated the pull request. Re-import the pull request |
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
facebook-github-bot
pushed a commit
that referenced
this pull request
Apr 1, 2019
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: c21adb7 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: #980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth fbshipit-source-id: fc01757
facebook-github-bot
pushed a commit
that referenced
this pull request
Nov 18, 2019
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: c21adb7 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: #980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth fbshipit-source-id: f740c16
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 23, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth fbshipit-source-id: f740c16
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 23, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 24, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 28, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 28, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 29, 2020
Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lth Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 23, 2023
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
hermanlee
pushed a commit
to hermanlee/mysql-5.6
that referenced
this pull request
Oct 3, 2023
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
hermanlee
pushed a commit
to hermanlee/mysql-5.6
that referenced
this pull request
Oct 18, 2023
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 16, 2024
) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook/mysql-5.6@c21adb7 Reference commit: facebook/mysql-5.6@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook/mysql-5.6#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 17, 2024
) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook/mysql-5.6@c21adb7 Reference commit: facebook/mysql-5.6@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook/mysql-5.6#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 23, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 25, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 7, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 8, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 9, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 10, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 13, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 15, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 16, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 17, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 30, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 13, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 14, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 19, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 20, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 21, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 25, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 2, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 31, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 2, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 6, 2024
…k#980) Summary: For a first review, I only added the code changes to this pull request for two reasons: * a full test is still running, and I'll have to check the results (I do see a few non output only failures because timeouts, so looks like I missed some nsec-sec conversion in this diff - I'll fix that and update). And checking output changes / rerecording will take time. * compared to the 5.6 patch, the code change for 8.0 is huge, and affects the service api - reviewing only the code changes is probably a good idea Jira ticket: https://jira.percona.com/browse/FB8-104 Reference commit: facebook@c21adb7 Reference commit: facebook@25f0f276d13 Currently lock_wait_timeout is an integer type variable which only have seconds resolution. We would want to extend the variable to double/decimal type, so it can have milliseconds or microseconds resolution, such as lock_wait_timeout = 1.23. The integral part should still mean seconds to keep backward compatibility. The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below 1 second; such as lock_wait_timeout = 0.005. Values that are too small will effectively mean not waiting for locks. This update also changes the output of lock_wait_timeout to be decimal; note the extra .000000 appended to the seconds. SELECT global.lock_wait_timeout; global.lock_wait_timeout 604800.000000 Pull Request resolved: facebook#980 Reviewed By: lloyd Differential Revision: D14349342 Pulled By: lth
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For a first review, I only added the code changes to this pull request for two reasons:
Jira ticket: https://jira.percona.com/browse/FB8-104
Reference commit: c21adb7
Currently lock_wait_timeout is an integer type variable which only have
seconds resolution. We would want to extend the variable to double/decimal
type, so it can have milliseconds or microseconds resolution, such as
lock_wait_timeout = 1.23. The integral part should still mean seconds to
keep backward compatibility.
The range of valid values expanded to [ 0 .. 604800 ] to allow timeouts below
1 second; such as lock_wait_timeout = 0.005. Values that are too small
will effectively mean not waiting for locks.
This update also changes the output of lock_wait_timeout to be decimal;
note the extra .000000 appended to the seconds.