fix(db): retire legacy cad_buildings_pkey before rename — fix migration 92 (#168 hotfix)

Migration 92_cad_bulk_layers.sql fails on deploy with:
  ERROR: relation "cad_buildings_pkey" already exists
  CONTEXT: ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey

Root cause: K.1 renamed cad_buildings → cad_buildings_old_apr26, but PG
does NOT auto-rename the backing PK index on table rename. The legacy
cad_buildings_pkey index is still attached to cad_buildings_old_apr26.
K.3 then tries to rename cad_buildings_new_pkey to the same name → collision.

Fix: add an explicit `ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO
cad_buildings_old_apr26_pkey` BEFORE the new rename. Idempotent (IF EXISTS).

Migration 92 was rolled back in last 3 deploy attempts (not in
_schema_migrations), so this edit will re-apply cleanly on next deploy.
This commit is contained in:
lekss361 2026-05-15 13:51:24 +03:00
parent ced237804d
commit e2d1ce3679

View file

@ -503,6 +503,12 @@ BEGIN
WHERE table_schema = 'public' AND table_name = 'cad_buildings'
) THEN
ALTER TABLE cad_buildings_new RENAME TO cad_buildings;
-- First, retire the legacy PK index name that's still attached to
-- cad_buildings_old_apr26 (PG does NOT auto-rename PK indexes on
-- table rename — pre-K.1 backup left cad_buildings_pkey behind).
-- Without this rename, the next line collides with the existing
-- index name → 'relation already exists' → tx rollback.
ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO cad_buildings_old_apr26_pkey;
-- Rename indexes to drop the _new suffix
ALTER INDEX IF EXISTS cad_buildings_new_pkey RENAME TO cad_buildings_pkey;
-- Note: ALTER INDEX RENAME on a PK index also renames the constraint