-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
"attempt-instant-ddl" should support lock_wait_timeout #1386
Comments
Peering into #1201, I found it perplexing that it says this in the docs:
This is really critical information, in my opinion, because if gh-ost is supposed to be inherently safe, it seems to jeopardize this safety by potentially creating table outages with no controllable timeout here. We primarily introduced gh-ost because of long-running transactions that were hard to pin down and a lack of safety with LHM in these scenarios. While we've mostly cleaned these up, I still think anything that could remotely incur a table outage should have defined characteristics for how long the table will be out. |
Addresses github#1386 by reusing the cut-over-lock-timeout from the cutover code. The lock wait timeout in the original code is actually set to double the setting, so we keep that consistent.
Addresses github#1386 by reusing the cut-over-lock-timeout from the cutover code. The lock wait timeout in the original code is actually set to double the setting, so we keep that consistent.
Currently gh-ost only sets
lock_wait_timeout
when doing normal cutover: https://github.com/search?q=repo%3Agithub%2Fgh-ost%20lock_wait_timeout&type=codeWhen Instant DDL is used, there doesn't seem to be a way to set the lock timeout. We can either reuse the same
cut-over-lock-timeout-seconds
flag or introduce a new one specifically for Instant DDL.The text was updated successfully, but these errors were encountered: