I don't know why, off hand, but I see the following sequence of events after doing an INSERT INTO .... SELECT ....:

Vertica::Query#initialize
Vertica::Query#handle_data_row(#<Vertica::Protocol::DataRow:0x0000560c3f2a31d0 @values=["0"]>)
Vertica::Query#handle_command_complete(#<Vertica::Protocol::CommandComplete:0x0000560c3f293280 @tag="">)
Vertica::Query#handle_data_row(#<Vertica::Protocol::DataRow:0x0000560c3f290f80 @values=["0"]>)
/opt/nexia_analytics_loader/shared/vendor/bundle/ruby/2.4.0/gems/vertica-1.0.3/lib/vertica/query.rb:109:in `buffer_row': undefined method `<<' for nil:NilClass (NoMethodError)

What happens is, @buffer_row in Vertica::Query is initialized (correctly) to [] in #initialize, appended to in the first #handle_data_row call, and replaced with nil in handle_command_complete. Then, for some reason, we get a data row afterwards, and that tries to call #buffer_row with a nil @buffer.

I was able to work around this by

diff --git a/lib/vertica/query.rb b/lib/vertica/query.rb
index ce0c7fd..f3ed77a 100644
--- a/lib/vertica/query.rb
+++ b/lib/vertica/query.rb
@@ -104,6 +104,7 @@ class Vertica::Query
   end

   def buffer_row(row)
+    @buffer ||= []
     @buffer << row
   end

but I don't think this is necessarily the best solution. However, in the absence of a better idea, I think not crashing when data comes back in an unexpected order is desirable.