Fehler #640
geschlossen
DBUpgrade fehler bei sql/Pg-upgrade2/oe_purchase_order_confirmation_order_types.sql
Von Cem Aydin vor etwa 1 Jahr hinzugefügt.
Vor 12 Monaten aktualisiert.
Beschreibung
Hallo,
bei mir lokal kommt nach einem pull (master), beim db upgrade:
Fehler!
The database update/creation did not succeed. The file sql/Pg-upgrade2/oe_purchase_order_confirmation_order_types.sql containing the following query failed:
ALTER TYPE order_types ADD VALUE IF NOT EXISTS 'purchase_order_confirmation'
The error message was: FEHLER: ALTER TYPE ... ADD kann nicht in einem Transaktionsblock laufen
All changes in that file have been reverted.:
Es scheint, dass das problem möglicherweise bei älteren postgres versionen auftritt, gemäß kommentaren, nicht mehr ab PG V. 12.:
https://stackoverflow.com/questions/53149484/error-alter-type-add-cannot-run-inside-a-transaction-block
Lokal habe ich PG V. 11.
Möglicherweise geht es auch, wenn man die query manuell ausführt (gemäß kommentaren im link).
Dateien
Hmmm, manuell ausführen geht aber der fehler tritt trotzdem noch auf...
- Zielversion wurde auf 3.9 gesetzt
Hi - wollte auch gerade ein Ticket erstellen, da mit nicht ganz klar ist, wie wir damit umgehen sollen.
Ab PostgreSQL Version 12 geht das. Davor kann "ALTER TYPE ... ADD ..." nicht in einer Transaktion ausgeführt werden.
Du kannst die Query im Upgrade-Skript auskommentieren (damit es durchläuft und als gelaufen eingetragen wird) und dann direkt in der Datenbank die Query ausführen, damit es nicht in einer Transaktion läuft.
Die Lösungen für's Projekt wären meiner Meinung nach:
- PostgreSQL >= Version 12 verlangen; Doku und UPGRADE-Datei anpassen, evtl. dann auch noch im Installation-Check prüfen; Unterstützte Betriebssysteme in der Doku anpassen
und/oder
- Kommentar in der DB-Upgrade-Datei (evtl. eine Ausgabe beim Upgrade?) und Erläuterung in doc/UPGRADE, wie man dass dann händisch löst
- Zielversion
3.9 wurde gelöscht
Du kannst die Query im Upgrade-Skript auskommentieren (damit es durchläuft und als gelaufen eingetragen wird) und dann direkt in der Datenbank die Query ausführen, damit es nicht in einer Transaktion läuft.
Ja, hab ich auch so gemacht, das hat funktioniert.
Bernd Bleßmann schrieb:
Die Lösungen für's Projekt wären meiner Meinung nach:
- PostgreSQL >= Version 12 verlangen; Doku und UPGRADE-Datei anpassen, evtl. dann auch noch im Installation-Check prüfen; Unterstützte Betriebssysteme in der Doku anpassen
und/oder
- Kommentar in der DB-Upgrade-Datei (evtl. eine Ausgabe beim Upgrade?) und Erläuterung in doc/UPGRADE, wie man dass dann händisch löst
Ja, denke ist beides möglich von mir aus. Das müsst ihr, beziehungsweise gemeinsam entschieden werden, was da das vorgehen ist. Wenn man offiziell PG V. 12 verlangt, wäre ja theoretisch der workaround trotzdem noch möglich.
Ist ja auch immer gut eine motivation zu haben zum upgraden :).
- Zielversion wurde auf 3.9 gesetzt
Damit das Datenbankupgradescript auch mit älteren Postgres-Versionen kompatibel ist, kann folgendes Script verwendet werden:
Statt:
ALTER TYPE order_types ADD VALUE IF NOT EXISTS 'purchase_order_confirmation';
Neu:
INSERT INTO pg_enum (
enumtypid,
enumlabel,
enumsortorder
)
SELECT
(SELECT oid FROM pg_type WHERE typname = 'order_types')::regtype::oid,
'purchase_order_confirmation',
(SELECT MAX + 1 FROM pg_enum WHERE enumtypid = (SELECT oid FROM pg_type WHERE typname = 'order_types')::regtype);
Spricht etwas dagegen, dass das Upgradescript entsprechend geändert wird?
Andreas Rudin schrieb:
Damit das Datenbankupgradescript auch mit älteren Postgres-Versionen kompatibel ist, kann folgendes Script verwendet werden:
Statt:
ALTER TYPE order_types ADD VALUE IF NOT EXISTS 'purchase_order_confirmation';
Neu:
INSERT INTO pg_enum (
enumtypid,
enumlabel,
enumsortorder
)
SELECT
(SELECT oid FROM pg_type WHERE typname = 'order_types')::regtype::oid,
'purchase_order_confirmation',
(SELECT MAX + 1 FROM pg_enum WHERE enumtypid = (SELECT oid FROM pg_type WHERE typname = 'order_types')::regtype);
Spricht etwas dagegen, dass das Upgradescript entsprechend geändert wird?
Hallo Andreas,
ja. Ich halte nicht so viel davon, im Postgres-System-Katalog direkt was zu ändern. Es wird ja einen Grund geben, warum das nicht geht.
Oder andersrum: Ich kann nicht beurteilen, was da alles passieren kann.
Viele Grüße
Bernd
PostgreSQL >= Version 12 verlangen; Doku und UPGRADE-Datei anpassen, evtl. dann auch noch im Installation-Check prüfen; Unterstützte Betriebssysteme in der Doku anpassen
Ich hab gerade nachgeschaut, Debian 10 (Buster) hat noch postgres 11. Das ist noch LTS Support und ist noch als empfohlen in der Dokumentation hinterlegt.
- Status wurde von Neu zu Erledigt geändert
Besprochen im Team. Entscheidung:
Debian Buster (LTS bis 2024) wird nicht mehr offiziell unterstützt.
> close, won't fix.
> neues Ticket um die Minmalanforderungen hochzusetzen in der Dokumentation.
Auch abrufbar als: Atom
PDF
