StandardmĂ€Ăig betrachtet PostgreSQL beim ĂberprĂŒfen der Eindeutigkeit eines Tupels zur Durchsetzung eines eindeutigen Indexes NULL-Werte als unterschiedliche Werte. Aus diesem Grund könnten wir aufgrund von Race Conditions fĂ€lschlicherweise mehrere EintrĂ€ge mit { identifier: \"rails_env\", target: nil } erstellen. Dies wĂŒrde dann zu Fehlern zur Laufzeit fĂŒhren.
Wie löst dies das Problem?
Löschen Sie den vorhandenen Index und erstellen Sie ihn mit der Option NULLS NOT DISTINCT neu.
Problem
NULLS NOT DISTINCT wurde jedoch eingefĂŒhrt in Postgres 15 beta2. Die aktuelle Postgres-Version bei einer Standardinstallation ist Postgres 13 und diese unterstĂŒtzt diese Funktion nicht.
Konsequenzen
Diese Ănderung hat keine Auswirkungen auf PG13, da NULLS NOT DISTINCT ignoriert wird (Quelle).
Der Versuch, ein Backup von einem PG15-Server auf einem PG13-Server wiederherzustellen, schlÀgt mit der folgenden Fehlermeldung fehl:
ERROR: syntax error at or near "NULLS"
LINE 1: ...m_check_trackers USING btree (identifier, target) NULLS NOT ...
^
EXCEPTION: psql failed: ^
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
(vollstÀndige Zeile: CREATE UNIQUE INDEX index_problem_check_trackers_on_identifier_and_target ON public.problem_check_trackers USING btree (identifier, target) NULLS NOT DISTINCT;)
@drenmi Sieht so aus, als mĂŒssten wir die Migration rĂŒckgĂ€ngig machen und eine andere Lösung in Betracht ziehen. Dies verursacht wahrscheinlich Fehler bei selbst gehosteten Installationen.
Nun, ich kann nicht fĂŒr andere sprechen und ich weiĂ nicht, ob ich wirklich reprĂ€sentativ bin (wahrscheinlich nicht), aber ich bin ihm zweimal innerhalb von 3 Tagen nach dieser Ănderung begegnetâŠ
Daher wĂ€re eine Umgehung (und RĂŒckgĂ€ngigmachung!) sehr willkommen.
Da wir jetzt die Problemumgehung haben, die auch bei PG15 funktionieren sollte, sollten wir NULLS NOT DISTINCT entfernen können.
Aus reiner Neugier, was haben Sie getan, dass die Wiederherstellung eines PG15-Backups auf PG13 notwendig war? (Das hat keine Auswirkungen auf die obige Aufgabe, ich versuche nur, so gut wie möglich zu verstehen, was âin freier Wildbahnâ passiert.)
Wir hatten einen Kunden, der versuchte, ein Backup wiederherzustellen (ich glaube, er war selbst gehostet und hatte Dinge versucht, die ĂŒber sein Wissen hinausgingen ), und wir hatten einen anderen Kunden, der uns bat, eine Staging-Site fĂŒr die Entwicklung benutzerdefinierter Plugins einzurichten, und wir haben ein Backup von CDCK-Hosting ĂŒbernommen.
Im Allgemeinen funktioniert der integrierte Versionierungsmechanismus in den Backup-Metadaten sehr gut, um proaktiv festzustellen, ob etwas explodieren wird oder nicht, aber diese Art von Situationen* sind wie Minenfelder
(* TatsĂ€chlich ist das Einzige, was mir sonst noch einfĂ€llt und nicht von der Migrationsversionierung abgedeckt wird, wenn eine Migration mit einem Ă€lteren Zeitstempel in den Main-Branch eingefĂŒgt wird, aber das schweift ab)
Ich kann sehen, dass das Problem bereits behoben ist, aber um eine Erfahrung aus der Praxis hinzuzufĂŒgen: Ich hatte dieses Problem, als ich versuchte, ein Backup, das auf einer Discourse-gehosteten Instanz erstellt wurde, auf einen Dev-Container wiederherzustellen, den ich lokal mit Docker eingerichtet hatte, als Teil der Einrichtung einer Entwicklungsumgebung. Anscheinend lĂ€uft Discourse Hosting PG 15, aber die Entwicklungsumgebung ist 13?
Ja, das ist die Wurzel des Problems. Wir mĂŒssen unseren Open-Source-Container auf 15 aktualisieren. Wir werden uns in den nĂ€chsten Monaten darum kĂŒmmern.
(Das hat keine Auswirkungen auf die obige Aufgabe, ich versuche nur, so gut wie möglich zu verstehen, was âin freier Wildbahnâ passiert.)
), und wir hatten einen anderen Kunden, der uns bat, eine Staging-Site fĂŒr die Entwicklung benutzerdefinierter Plugins einzurichten, und wir haben ein Backup von CDCK-Hosting ĂŒbernommen.