The current ghostferry-copydb default behavior is to use set the RowLock property on the data-iterator when copying over rows from the source to the target DB. Unfortunately the reason why is not documented very well (that I could find).

This default behavior means that it is not possible to replicate from a MySQL slave DB, because such a server typically is run in READ-ONLY mode, preventing the SELECT ... FOR UPDATE used by ghostferry.

My assumption is that this is to keep the data consistent between the reading and the row verification. Beyond verification, it should be safe to operate without the FOR UPDATE (which also improves performance, as we don't require the round-trips for the transaction, which is always rolled back anyways), because any modifications on the source DB overlapping with a row read should be "fixed" by the binlog-writer anyways.
Can you confirm my assumption is correct?

If so, would it make sense to disable the use of RowLock = true if no verifier is enabled, or at least allow the DataIterator to allow disabling the row-lock as part of the constructor?