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:
parent
ced237804d
commit
e2d1ce3679
1 changed files with 6 additions and 0 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue