-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Replacing reference of SECOND_FRAC (deprecated) for MICROSECOND #43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi, thank you for submitting this pull request. In order to consider your code we need you to sign the Oracle Contribution Agreement (OCA). Please review the details and follow the instructions at http://www.oracle.com/technetwork/community/oca-486395.html |
Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment: |
I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it. |
Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow |
…n family Summary: Fix issue mysql#42. Also issue mysql#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue mysql#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
…n family Summary: Fix issue mysql#42. Also issue mysql#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue mysql#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Dockerfile: add zstd (8.0)
Bug: 60628