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

Merged

lekss361 merged 1 commit from fix/cadastre-schema-pkey-rename into main

2026-05-15 10:59:53 +00:00

lekss361 commented

2026-05-15 10:51:29 +00:00

(Migrated from github.com)

Summary

Hotfix для #168 — auto-apply migration 92 уронил deploy 3× подряд
Root cause: K.3 пытается ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey, но имя уже занято — старый PK index остался на backup-таблице

Error from deploy logs

ERROR: relation "cad_buildings_pkey" already exists
CONTEXT: SQL statement "ALTER INDEX IF EXISTS cad_buildings_new_pkey RENAME TO cad_buildings_pkey"

Why this happens

K.1 ALTER TABLE cad_buildings RENAME TO cad_buildings_old_apr26 — table renamed ✓
PG does NOT auto-rename PK indexes when table renames — cad_buildings_pkey остался на cad_buildings_old_apr26
K.3 try ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey → collision

Fix

Add explicit rename of legacy PK index BEFORE new rename:

ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO cad_buildings_old_apr26_pkey;  -- new line
ALTER INDEX IF EXISTS cad_buildings_new_pkey RENAME TO cad_buildings_pkey;        -- existing

IF EXISTS makes it idempotent. Comment explains why.

State on prod

Migration 92 transaction rolled back (3× failures) → NOT in _schema_migrations.
After merge → next deploy will re-run 92 fresh с этим фиксом → success.

Test plan

Edit one block in 92_cad_bulk_layers.sql
After merge → deploy.yml успешно apply migration 92 (logs show CREATE INDEX × 22 + ALTER INDEX × 7 + COMMIT)
\dt cad_* показывает 7 новых таблиц + cad_buildings + cad_buildings_old_apr26
\di cad_buildings* показывает оба cad_buildings_pkey и cad_buildings_old_apr26_pkey

Closes hotfix path of #168.

## Summary - **Hotfix** для #168 — auto-apply migration 92 уронил deploy 3× подряд - Root cause: K.3 пытается `ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey`, но имя уже занято — старый PK index остался на backup-таблице ## Error from deploy logs ``` ERROR: relation "cad_buildings_pkey" already exists CONTEXT: SQL statement "ALTER INDEX IF EXISTS cad_buildings_new_pkey RENAME TO cad_buildings_pkey" ``` ## Why this happens 1. K.1 `ALTER TABLE cad_buildings RENAME TO cad_buildings_old_apr26` — table renamed ✓ 2. **PG does NOT auto-rename PK indexes** when table renames — `cad_buildings_pkey` остался на `cad_buildings_old_apr26` 3. K.3 try `ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey` → collision ## Fix Add explicit rename of legacy PK index BEFORE new rename: ```sql ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO cad_buildings_old_apr26_pkey; -- new line ALTER INDEX IF EXISTS cad_buildings_new_pkey RENAME TO cad_buildings_pkey; -- existing ``` `IF EXISTS` makes it idempotent. Comment explains why. ## State on prod Migration 92 transaction rolled back (3× failures) → **NOT in `_schema_migrations`**. After merge → next deploy will re-run 92 fresh с этим фиксом → success. ## Test plan - [x] Edit one block in 92_cad_bulk_layers.sql - [ ] After merge → deploy.yml успешно apply migration 92 (logs show CREATE INDEX × 22 + ALTER INDEX × 7 + COMMIT) - [ ] `\dt cad_*` показывает 7 новых таблиц + cad_buildings + cad_buildings_old_apr26 - [ ] `\di cad_buildings*` показывает оба cad_buildings_pkey и cad_buildings_old_apr26_pkey Closes hotfix path of #168.

lekss361 commented

2026-05-15 10:59:32 +00:00

(Migrated from github.com)

Final review (SHA verified, CI ✅) — critical hotfix

Cross-checked агентом — fix корректен, дополнительно подтверждено: 2 deploy workflows на main падали (после merges #171, #172). Production не получает новые изменения с момента #169 deploy attempt.

Bug (verified)

K.1: ALTER TABLE cad_buildings RENAME TO cad_buildings_old_apr26 ✓ rename'ит table
PG behavior: PK indexes НЕ rename'ятся с table — cad_buildings_pkey остался прикреплён к cad_buildings_old_apr26
K.3 attempt ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey → relation already exists → tx rollback

Fix correctness

✅ Surgical +6/-0 — добавлена 1 line: ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO cad_buildings_old_apr26_pkey; ПЕРЕД K.3 collision
✅ IF EXISTS на обоих rename — idempotent
✅ Внутри existing IF NOT EXISTS cad_buildings guard — preserves once-only invariant
✅ Comment explains why rename нужен

Modify-in-place justified

✅ Migration 92 транзакция rolled back 3× → никогда не была в _schema_migrations → edit existing file корректно. NN_NN.sql не нужен.

State

✅ CI green (backend + frontend SUCCESS)
✅ mergeable=MERGEABLE, mergeStateStatus=CLEAN
✅ Никаких manual ops на prod не требуется
✅ Backend code не зависит от PK names (FK резолвится через table+col, не constraint name)

Lesson learned для меня

Мой previous agent review #169 confirmed K.3 fix как "ALTER INDEX RENAME уже rename'ит PK constraint automatically" — но не заметил что cad_buildings_pkey уже занят старым PK на backup table. Это subtle PG schema interaction которое CI не отловило бы без реального run на DB с existing data. На будущее — для migrations с RENAME операциями стоит специально проверять что target names не conflict с indexes сохранившимися от прошлых objects.

approve merge

## Final review (SHA verified, CI ✅) — critical hotfix Cross-checked агентом — fix корректен, **дополнительно подтверждено: 2 deploy workflows на main падали** (после merges #171, #172). Production не получает новые изменения с момента #169 deploy attempt. ### Bug (verified) - K.1: `ALTER TABLE cad_buildings RENAME TO cad_buildings_old_apr26` ✓ rename'ит table - **PG behavior**: PK indexes НЕ rename'ятся с table — `cad_buildings_pkey` остался прикреплён к `cad_buildings_old_apr26` - K.3 attempt `ALTER INDEX cad_buildings_new_pkey RENAME TO cad_buildings_pkey` → `relation already exists` → tx rollback ### Fix correctness ✅ **Surgical +6/-0** — добавлена 1 line: `ALTER INDEX IF EXISTS cad_buildings_pkey RENAME TO cad_buildings_old_apr26_pkey;` ПЕРЕД K.3 collision ✅ **IF EXISTS** на обоих rename — idempotent ✅ **Внутри existing `IF NOT EXISTS cad_buildings` guard** — preserves once-only invariant ✅ **Comment explains why** rename нужен ### Modify-in-place justified ✅ Migration 92 транзакция rolled back 3× → **никогда не была в `_schema_migrations`** → edit existing file корректно. NN_NN.sql не нужен. ### State ✅ CI green (backend + frontend SUCCESS) ✅ mergeable=MERGEABLE, mergeStateStatus=CLEAN ✅ Никаких manual ops на prod не требуется ✅ Backend code не зависит от PK names (FK резолвится через table+col, не constraint name) ### Lesson learned для меня Мой previous agent review #169 confirmed K.3 fix как "ALTER INDEX RENAME уже rename'ит PK constraint automatically" — но **не заметил что `cad_buildings_pkey` уже занят старым PK на backup table**. Это subtle PG schema interaction которое CI не отловило бы без реального run на DB с existing data. На будущее — для migrations с RENAME операциями стоит специально проверять что target names не conflict с indexes сохранившимися от прошлых objects. approve merge