pg_ha_migrations 2.3.0 → 2.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8221b8e9b26c975a4f9746ced6be9b17aab3a68b04dd190c93eb20a32ccda3ea
-  data.tar.gz: 67783da5f9b25e12efff7f5a49aea5dc2ba4b00161492392c933329ab024cce7
+  metadata.gz: 2092871922f1fb41ad0d82a1cda3b1b8ad57bf03b9e9a324d452110926754dba
+  data.tar.gz: 9e1e74c22f51cdf6d36333fdd6740ebdd5d5d4e76053a000859e7027b39ac9e5
 SHA512:
-  metadata.gz: ec9164fdd0eb88a27b2e67fd556506ae9cfdf156ca56c53703e55798125869ebd77b6eb9538bf9b40e473d270e647409d3ed6ba074a273d2d262123441fd3171
-  data.tar.gz: 14b92ab3840fa46aabc860f762c95bb9cad4b71d6d8e48996109777dd796ffa801601fd3e0ee0262a28c1f91adbd35cd092ca90ff9c2f35319235e2e15d7f0b3
+  metadata.gz: 88089a7139e0ec580ff9c32574b4fd890d7bf7203740e6d3ec4821a6d03aed728868602de5347b441a2607951234b157cd19485710591b37e27dda803f4f46c7
+  data.tar.gz: a52081ab69232926e4484ac0d551437f61b719e0d1514cba507dcbcaf97c363726f2729037170e452f7d7d153847601604f50f92a837a374afc854e0d37f46d1

data/README.md

@@ -63,9 +63,21 @@ We believe the `force: true` option to ActiveRecord's `create_table` method is a
 
 ### Rollback
 
-Because we require that ["Rollback strategies do not involve reverting the database schema to its previous version"](https://medium.com/paypal-tech/postgresql-at-scale-database-schema-changes-without-downtime-20d3749ed680#360a), PgHaMigrations does not support ActiveRecord's automatic migration rollback capability.
+Although some schema changes are safe to reverse (e.g., dropping a just-created non-unique index), most possible schema changes are not safe to reverse. A few examples relative to database integrity:
+* Dropping a newly added column may result in data loss.
+* Re-adding a dropped unique index (or any other constraint) may fail because data may now exist that violates the constraint.
+* Dropping a enum value simply isn’t supported by Postgres (and wouldn’t be safe since it might be referenced by rows in the database).
 
-Instead we write all of our migrations with only an `def up` method like:
+These concerns are magnified if we also consider currently running application code (especially across multiple revisions, i.e., during a deploy). For example, the application may expect:
+* Indexes to be present for performant queries.
+* Constraints to hold.
+* Columns to be present.
+
+Therefore we require that ["Rollback strategies do not involve reverting the database schema to its previous version"](https://medium.com/paypal-tech/postgresql-at-scale-database-schema-changes-without-downtime-20d3749ed680#360a), and PgHaMigrations does not support ActiveRecord's automatic migration rollback capability.
+
+Instead we concentrate on ensuring that operations are safe to apply while both old and new revisions of an application are running. In the rare case where we need to “undo” a schema change, we roll forward, rather than rolling back, by having an engineer write a new schema change and deploying that change.
+
+We write all of our migrations with only an `def up` method like:
 
 ```
 def up
@@ -73,7 +85,9 @@ def up
 end
 ```
 
-and never use `def change`. We believe that this is the only safe approach in production environments. For development environments we iterate by recreating the database from scratch every time we make a change.
+and never use `def change`.
+
+For development environments we iterate by recreating the database from scratch every time we make a change.
 
 ### Transactional DDL
 

data/lib/pg_ha_migrations/safe_statements.rb

@@ -326,6 +326,31 @@ module PgHaMigrations::SafeStatements
       PgHaMigrations::Index.from_table_and_columns(child_table, columns)
     end
 
+    # A previous run that was interrupted mid-build can leave an invalid index
+    # behind on a child partition. Because CREATE INDEX ... IF NOT EXISTS matches
+    # on name only (not validity), that leftover would be skipped and never
+    # rebuilt, so the parent index would never become valid and this method
+    # would raise below on every re-run. When resuming (if_not_exists), drop any
+    # invalid child leftovers first so they get rebuilt. They are unattached at
+    # this point (the attach step runs only after every child index is built),
+    # so they can be dropped concurrently.
+    if if_not_exists && child_indexes.present?
+      quoted_child_index_names = child_indexes.map { |child_index| connection.quote(child_index.name) }.join(", ")
+
+      invalid_child_index_names = connection.select_values(<<~SQL)
+        SELECT pg_class.relname
+        FROM pg_index
+          JOIN pg_class ON pg_class.oid = pg_index.indexrelid
+        WHERE NOT pg_index.indisvalid
+          AND pg_class.relkind = 'i'
+          AND pg_class.relname = ANY (ARRAY[#{quoted_child_index_names}])
+      SQL
+
+      child_indexes.select { |index| invalid_child_index_names.include?(index.name) }.each do |child_index|
+        safe_remove_concurrent_index(child_index.table.fully_qualified_name, name: child_index.name)
+      end
+    end
+
     # CREATE INDEX ON ONLY parent_table
     unsafe_add_index(
       parent_table.fully_qualified_name,

data/lib/pg_ha_migrations/version.rb

@@ -1,3 +1,3 @@
 module PgHaMigrations
-  VERSION = "2.3.0"
+  VERSION = "2.3.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: pg_ha_migrations
 version: !ruby/object:Gem::Version
-  version: 2.3.0
+  version: 2.3.1
 platform: ruby
 authors:
 - celeen
@@ -13,7 +13,7 @@ authors:
 - redneckbeard
 bindir: exe
 cert_chain: []
-date: 2026-01-13 00:00:00.000000000 Z
+date: 2026-07-31 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rake