Comment 3 for bug 1182180

This is the same as bug 1020997. The root problem is IndexLength::index_length() which is used for --check-plan. So the workaround is: --no-check-plan.

I'm going to un-target this from 2.24 because this will require more work to fix in pt-table-checksum. For pt-osc, we could simply not copy any rows, but ptc needs to work on empty tables.

The problem, as described in bug 1020997, arises when the table had lots of rows that were deleted but the InnoDB stats were not updated. The tool sees that the table has 500k rows, for example, so it decides to nibble/chunk it. For --check-plan, the tool checks that MySQL is using the full nibble index. Doing this requires a row, so IndexLength::length() calls IndexLength::_get_first_values() which returns $vals = undef because there are no rows, but it doesn't check this, it simply passes it to IndexLength::_make_range_query() which expects a defined $vals arg, hence the error.

For ptc, we need to detect this and revert from nibble the table to single-chunking it. Problem is: the current code doesn't make this possible. The IndexLength calls happen after the tool decides whether or not to nibble, so there's no simple way yet to re-do the table or revert to single-chunking. The other consideration is: we plan to do away with single chunking altogether.

We'll fix this, but it will take some time. In the meantime, using --no-check-plan will avoid this, but be careful when disabling this safety.