Par défaut, lors de la vérification de l’unicité d’un tuple aux fins de l’application d’un index unique, PostgreSQL considère les NULL comme des valeurs distinctes. En raison de cela, nous pourrions avoir plusieurs entrées incorrectes avec { identifier: \"rails_env\", target: nil } créées en raison de conditions de concurrence. Cela entraînerait alors des erreurs à l’exécution.
Comment cela résout-il le problème ?
Supprimer l’index existant et le recréer avec l’option NULLS NOT DISTINCT.
Problème
Cependant, NULLS NOT DISTINCT a été introduit dans Postgres 15 beta2. La version actuelle de Postgres dans une installation standard est Postgres 13 et celle-ci ne prend pas en charge cette fonctionnalité.
Conséquences
ce changement n’aura aucun effet sur PG13 puisque NULLS NOT DISTINCT sera ignoré (source)
tenter de restaurer une sauvegarde d’un serveur PG15 sur un serveur PG13 échouera avec l’erreur suivante
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'
(ligne complète : CREATE UNIQUE INDEX index_problem_check_trackers_on_identifier_and_target ON public.problem_check_trackers USING btree (identifier, target) NULLS NOT DISTINCT;)
@drenmi On dirait que nous devons annuler la migration et reconsidérer une autre solution. Cela provoque probablement des erreurs dans les installations auto-hébergées.
J’ai une PR ici qui devrait également fonctionner pour PG13.
Nous réfléchissons encore à la faisabilité de ce cas dans la nature et à l’investissement que nous devrions potentiellement consacrer pour le contourner.
Eh bien, je ne peux pas parler pour les autres et je ne sais pas si je suis vraiment représentatif (probablement pas), mais je l’ai rencontré deux fois en 3 jours après que ce changement a été effectué…
Donc, une solution de contournement (et un retour arrière !) serait très appréciée.
Maintenant que nous avons la solution de contournement, qui devrait également fonctionner sur PG15, nous devrions pouvoir supprimer NULLS NOT DISTINCT.
Par curiosité, que faisiez-vous qui a nécessité la restauration d’une sauvegarde PG15 sur PG13 ? (Cela n’affectera pas la tâche ci-dessus, j’essaie juste de comprendre ce qui se passe « dans la nature » autant que possible.)
Nous avons eu un client qui tentait de restaurer une sauvegarde (je pense qu’il était auto-hébergé et qu’il avait essayé des choses au-delà de son niveau de connaissance ), et nous avons eu un autre client qui nous a demandé de mettre en place un site de staging à des fins de développement de plugins personnalisés et nous avons effectué une sauvegarde de l’hébergement CDCK.
En général, le mécanisme de versioning intégré dans les métadonnées de sauvegarde fonctionne très bien pour déterminer de manière proactive quand quelque chose va échouer ou non, mais ce genre de situations* sont comme des mines terrestres
(* En fait, la seule autre chose à laquelle je peux penser qui n’est pas couverte par le versioning de migration est lorsqu’une migration avec un ancien horodatage est injectée dans la branche principale, mais je m’égare)
Je peux voir que le problème est déjà résolu, mais pour ajouter une expérience concrète : j’ai rencontré ce problème en essayant de restaurer une sauvegarde créée sur une instance hébergée par Discourse vers un conteneur de développement que j’avais configuré localement à l’aide de Docker dans le cadre de la mise en place d’un environnement de développement. Il semble que l’hébergement Discourse exécute PG 15 alors que l’environnement de développement est en version 13 ?
Oui, c’est la racine du problème, nous devons mettre à jour notre conteneur open source vers la version 15. Nous nous en occuperons dans les prochains mois.
(Cela n’affectera pas la tâche ci-dessus, j’essaie juste de comprendre ce qui se passe « dans la nature » autant que possible.)
), et nous avons eu un autre client qui nous a demandé de mettre en place un site de staging à des fins de développement de plugins personnalisés et nous avons effectué une sauvegarde de l’hébergement CDCK.