ankane
Check stv_inflight for query PID for redshift cancel
This PR modifies the cancel method for redshift to consider both STV_INFLIGHT over STV_RECENTS system tables. For some setups of Redshift, we are finding that getting the currently running query is more reliable to search the STV_INFLIGHT over STV_RECENTS. In these setups, the query will show up in the former table and not in the latter table until after the query has finished. I'm not totally certain why that is, but suspect it's something to do with the nature of cluster nodes, but the whole thing is opaque and I couldn't find any good concrete information on googling. A downside here is that STV_INFLIGHT includes a lot less query text (100 vs 600) for some reason, so inclusion of both tables seems the best strategy. One thought would be to prepend the comment with run information (followed by a newline) to the query so that it's always at the beginning and so therefore always present before truncation.
The join here shouldn't add too much additional overhead, but I don't have a heavily used Redshift cluster to verify against.
Not sure why the build suite is failing here, and I don't know enough about Ruby ecosystem or this project to know where to start.
Hey @MasterOdin, thanks for the PR! Will dig into this next time I'm working with Redshift (not sure when that'll be exactly).
