It looks like the backtrace is coming from libz somewhere via libcrypto, libssl, and libpq. If it happens again, a backtrace from gdb with local variables might help at least narrow down what code is responsible. You can do that with bt full from the crashed thread.
At this point I'm inclined to say that the problem is coming from an upstream library based on the fact that the backtrace is going through PQgetResult, but I'm happy to help try to figure out where that is if I'm able.
I don't have enough experience with Heroku to know whether it's possible to get a gdb backtrace or not. I suspect you'd need to work that into the way the application is launched or something, which may not be desirable in your production environment.
Another thing which might help narrow this down is to grab the exact query that's being run and trying to run it outside of your application's context. It looks like it's happening when the result of the query is being fetched, so it might happen even from psql or at least inside an IRB session or similar.
You may be able to narrow it down easier than trial-and-error by logging what the particulars of the query are before line 20 of /forms/twitter_search_result_form.rb, which looks to be the last line of Ruby before the segfault.