Do we really need this flag? I'm absolutely sure that mysql replication uses READ_COMMITTED when applying RBR changes from the binlog. As gh-ost does not support statement based replication, there's no point in using REPEATABLE_READ for the changelog applier and we should be able to use READ_COMMITTED always.

For the table copy part, I don't see a reason how READ_COMMITTED would have any negative side-effects either. Right now, REPEATABLE_READ might copy an "old" version of the row data, but the changelog applier will fix that up afterwards.

With READ_COMMITTED, we'll always read the "latest" version of the data, so in theory there could be less changes that need to be applied by the changelog applier, but I don't see any negative sides to this. 🤔

@arthurschreiber I pondered using READ_COMMITTED 100% in an earlier thread when setting transaction isolation was introduced, but there was some concerns around using a new isolation level. Allowing users that previously were using READ_COMMITTED before the enforcement was introduced seemed like the easiest way forward

But for the most part I agree, REPEATABLE_READ isolation is usually not required and can actually introduce stale results as you mention. There is one spot where a snapshot read might have a benefit, however: the calculation of the min/max chunk ranges. A snapshot isolation guarantees both the min and max query are operating on the same data - which sounds like a good thing but I'm not 100% sure