Increment @counter of prepared postgres statements prior to running t…

…he query, so if the query gets interrupted without Rails knowledge we don't end up with a crashed app in a state of perpetual failure to prepare the next query.

This commit directly inspired by the conversation at rails#25827 (and by a late night crash of our app due to this issue).

activerecord/CHANGELOG.md

@@ -1,3 +1,7 @@
+*   Increment postgres prepared statement counter before making a prepared statement, so if the statement is aborted 
+    without Rails knowledge (e.g., if app gets kill -9d during long-running query), app won't end 
+    up in perpetual crash state for being inconsistent with Postgres.
+
 *   Add `FinderMethods#sole` and `#find_sole_by` to find and assert the
     presence of exactly one record.
 

activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb

@@ -226,12 +226,9 @@ def initialize(connection, max)
           @counter = 0
         end
 
-        def next_key
-          "a#{@counter + 1}"
-        end
-
-        def []=(sql, key)
-          super.tap { @counter += 1 }
+        def incremented_next_key
+          @counter += 1
+          "a#{@counter}"
         end
 
         private
@@ -746,7 +743,7 @@ def prepare_statement(sql, binds)
           @lock.synchronize do
             sql_key = sql_key(sql)
             unless @statements.key? sql_key
-              nextkey = @statements.next_key
+              nextkey = @statements.incremented_next_key
               begin
                 @connection.prepare nextkey, sql
               rescue => e