Migration von Flyways hängt für Postgres CREATE INDEX CONCURRENTLY

Question

Ich versuche, einen CREATE INDEX CONCURRENTLY-Befehl gegen eine Postgres 9.2-Datenbank auszuführen. Ich habe einen MigrationsResolver implementiert, wie in Ausgabe 655 gezeigt. Wenn dieser Migrationsschritt über mvn flyway:migrate oder ähnlich ausgeführt wird, wird der Befehl gestartet, bleibt jedoch im Wartemodus hängen.

prüfte ich, dass der Befehl über die pg_stat_activity Tabelle ausführt:

test_2015_04_13_110536=# select * from pg_stat_activity; 
datid |  datname   | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port |   backend_start   |   xact_start   |   query_start   |   state_change   | waiting |  state  |                         query 
-------+------------------------+-------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
21095 | test_2015_04_13_110536 | 56695 | 16385 | postgres | psql    |    |     |   -1 | 2015-04-13 11:10:01.127768-06 | 2015-04-13 11:13:08.936651-06 | 2015-04-13 11:13:08.936651-06 | 2015-04-13 11:13:08.936655-06 | f  | active    | select * from pg_stat_activity; 
21095 | test_2015_04_13_110536 | 56824 | 16385 | postgres |     | 127.0.0.1 |     |  52437 | 2015-04-13 11:12:55.438927-06 | 2015-04-13 11:12:55.476442-06 | 2015-04-13 11:12:55.487139-06 | 2015-04-13 11:12:55.487175-06 | f  | idle in transaction | SELECT "version_rank","installed_rank","version","description","type","script","checksum","installed_on","installed_by","execution_time","success" FROM "public"."schema_version" ORDER BY "version_rank" 
21095 | test_2015_04_13_110536 | 56825 | 16385 | postgres |     | 127.0.0.1 |     |  52438 | 2015-04-13 11:12:55.443687-06 | 2015-04-13 11:12:55.49024-06 | 2015-04-13 11:12:55.49024-06 | 2015-04-13 11:12:55.490241-06 | t  | active    | CREATE UNIQUE INDEX CONCURRENTLY person_restrict_duplicates_2_idx ON person(name, person_month, person_year) 
(3 rows) 

Ein Beispiel-Projekt, das dieses Problem repliziert in meinem Github zu finden ist: chrisphelps/flyway-experiment

Mein Verdacht ist, dass die flyway Abfrage schema version Das ist idle in transaction verhindert postgres mit der Indexerstellung fortfahren.

Wie kann ich den Konflikt lösen, so dass Postgres mit der Migration fortfahren wird? War jemand in der Lage, diese Art von Migration auf Postgres via Flyway anzuwenden?

Answer 1

In der meantime ist ein Resolver in der Flyway enthalten, der nach etwas Magie im Dateinamen sucht.

Fügen Sie einfach das Präfix 'NT' (für N o- T ransaction) Ihre Migrationsdatei, i. e.

V01__usual_migration_1.sql

V02__another_migration.sql

NTV03__migration_that_does_not_run_in_transaction.sql

V04__classical_migration_4.sql

usw.