Gillian Gunson

@JGulbronson When gh-ost is in the cut-over process, it attempts (among other things) to get a write lock on the table being migrated; if it cannot (because of other connections'...

Note to self: We will likely want to add a note about the outcome of this to the docs (whether double encoding is a caveat, or requires a special flag,...

@tapuhi What version of mysql are you using? If the error on the `replace` statement, then the query is the one generated by gh-ost from parsing the binary logs. As...

tl;dr I say test it out, but I'm not sure. Here are my additional thoughts. 1. My understanding has been that `insert...select` does a shared read lock on the selected...

Some extra information on the incident: - gh-ost announced it was ready to cut-over 15 or so hours before the manual cut-over command was run - in the meantime, a...

This has repeated itself with the second execution of the same migration. It said it was ready to cut over, and it had only been 10 minutes between that announcement...

So, the column causing the problem is a timestamp, which shouldn't have any timezone attached to it *in storage*. And it's not getting updated in the update statements, only `counter`...

> "the problem is a timestamp, which shouldn't have any timezone attached to it" is not how it works. @druud I apologize for being unclear. As *stored* a timestamp has...