Elena Stepanova added a comment - 2017-01-02 12:44 Also reproducible on bb-10.2-monty as of 349d69e2e

Sergei Golubchik added a comment - 2017-02-08 21:12 I don't seem to be able to repeat it in the latest bb-10.2-serg (as of 8884b88a131)

Elena Stepanova added a comment - 2017-02-09 12:59 It disappeared from bb-10.2-serg starting from this revision: commit 8884b88a131201caee965ddbe3d43d392c44d1e3 Author: Sergei Golubchik <serg@mariadb.org> Date: Mon Feb 6 23:52:47 2017 +0100   MDEV-11640 gcol.gcol_select_myisam fails in buildbot on Power JOIN_CACHE's were initialized in check_join_cache_usage() from make_join_readinfo(). After that make_join_readinfo() was looking whether it's possible to use keyread. Later, after make_join_readinfo(), optimizer decided whether to use filesort. And even later, at the execution time, from join_read_first(), keyread was actually enabled. The problem is, that if a query uses a vcol, base columns that it depends on are automatically added to the read_set - because they're needed to calculate the vcol. But if we're doing keyread, vcol is taken from the index, not calculated, and base columns do not need to be in the read set (even should not be - as they aren't getting values). The bug was that JOIN_CACHE used read_set with base columns, they were not read because of keyread, so it was caching garbage. So read_set is only known after the keyread was decided. And after the filesort was decided, as filesort doesn't use keyread. But check_join_cache_usage() needs to be done in make_join_readinfo(), as the code below depends on these checks, Fix: keep JOIN_CACHE checks where they were, but move initialization down to the very end of JOIN::optimize_inner. If keyread was enabled, update the read_set to include only columns that are part of the index. Copy the keyread logic from join_read_first() to happen at optimize time.