dm-2

What do you think about just supporting `current` and `next`? I can't imagine that we'd want to spend much (any?) time on fixing issues specific to `min` and `previous` versions...

> CI is exploding at: > > ``` > Testing: timestamp-datetime..... > ERROR timestamp-datetime execution failure. cat /tmp/gh-ost-test.log: > 2022-09-06 14:05:50 INFO starting gh-ost 788e28ac7b449206a3d575ba90a1137440591c6b > 2022-09-06 14:05:50 INFO Migrating...

> do we meet some trouble on continuing to support for old version （5.5 5.6） ? > > In my company, most of mysql-instances will still be 5.6 in next...

@wangzhanbing please could you take a look at the merge conflict? Thank you! 🙇

Thanks for your contribution @debug-LiXiwen! 🙇 > 1. When the copyRowsQueue is not ready, you don't need to sleep manually, the select of the go language will be handled automatically...

Hi @devaraj-v, please can you provide a test case (table definition, `gh-ost` command, and error output) for this so we can see if we can reproduce the problem? Thanks!

:wave: @Shukla-Ankur It sounds like one of two things is happening, either: 1. gh-ost prioritises processing binlog changes over copying rows from the existing table, so if you're saturating your...

Fixed merge conflict for testing

@vbalys Would using a `gh-ost-on-success` hook to run `rename table ${GH_OST_OLD_TABLE_NAME} to ${GH_OST_OLD_TABLE_NAME}_${SOME_TIMESTAMP}` do what you're after? The `onSuccess()` hook is the [last](https://github.com/github/gh-ost/blob/02258ac15dc321b9e37876fef90ce69e5077544c/go/logic/migrator.go#L445) [thing](https://github.com/github/gh-ost/blob/02258ac15dc321b9e37876fef90ce69e5077544c/go/cmd/gh-ost/main.go#L303) to run before gh-ost exits after...

I'm closing this as it looks like we may have a solution, feel free to re-open if needed :+1: