Repository navigation
Refine wait_timeout override to be at cut-over only - #1406
timvaillancourt merged 2 commits into
Conversation
timvaillancourt
changed the title
wait_timeout override to be at cut-over only
shlomi-noach
left a comment
shlomi-noach
left a comment
There was a problem hiding this comment.
Nice work and in particular great analysis of this stalemate situation! This looks generally correct, but see inline comments:
- It break
gh-ostfor existing users - It adds variables where I think we can do without
- It adds code complexity which we can delegate to MySQL.
No, actually. The The next cut-over attempt will first, before placing any locks, attempt to This should be safe. |
@shlomi-noach that makes sense (eventually)! Thanks for the validations and explanations |
|
@shlomi-noach / @meiji163: I believe I've addressed the PR suggestions and this is ready for another review 🙇 |
4d670bd to
d0854d6
Compare
c660492 to
59db6fa
Compare
Signed-off-by: Tim Vaillancourt <tim@timvaillancourt.com>
3 participants
Related issue: #1407
Description
This PR refines #1401 by overriding the session
wait_timeoutonly where it is needed - at the cut-over time where an idle connection could lead to potentially-long table lock if thegh-ostprocess (or host running it) "freezes"/"stalls" at the cut-over stageThe change (at cut-over only):
wait_timeoutis fetched (via an existingselectthat fetchedtime_zone)wait_timeoutis set to be 3 x the lock-wait timeoutgh-oststalls with a still-active connection herewait_timeoutis restored to what it was set to pre-cut-overThe
--mysql-wait-timeoutflag added in #1401 is removed because it is no longer needed. No release has been cut since #1401, so this isn't necessarily a breaking changescript/cibuildreturns with no formatting errors, build errors or unit test errors.