Por defecto, al verificar la unicidad en una tupla con el fin de aplicar un índice único, PostgreSQL considera que los NULL son valores distintos. Debido a esto, podríamos tener incorrectamente múltiples entradas con { identifier: \"rails_env\", target: nil } creadas debido a condiciones de carrera. Esto luego causaría errores en tiempo de ejecución.
¿Cómo lo soluciona?
Eliminar el índice existente y recrearlo con la opción NULLS NOT DISTINCT.
Problema
Sin embargo, NULLS NOT DISTINCT se introdujo en Postgres 15 beta2. La versión actual de Postgres en una instalación estándar es Postgres 13 y no admite esta característica.
Consecuencias
este cambio no tendrá ningún efecto en PG13 ya que NULLS NOT DISTINCT será ignorado (fuente)
intentar restaurar una copia de seguridad de un servidor PG15 a un servidor PG13 fallará con el siguiente error
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'
(línea completa: CREATE UNIQUE INDEX index_problem_check_trackers_on_identifier_and_target ON public.problem_check_trackers USING btree (identifier, target) NULLS NOT DISTINCT;)
@drenmi Parece que tenemos que revertir la migración y considerar otra solución. Probablemente esto esté causando errores en las instalaciones autoalojadas.
Bueno, no puedo hablar por otros y no sé si soy verdaderamente representativo (probablemente no), pero me encontré con él dos veces en 3 días después de que se hiciera ese cambio…
Por lo tanto, se agradecería mucho una solución alternativa (¡y una reversión!).
Ahora que tenemos la solución alternativa, que también debería funcionar en PG15, deberíamos poder eliminar NULLS NOT DISTINCT.
Por curiosidad, ¿qué estabas haciendo que requirió restaurar una copia de seguridad de PG15 en PG13? (No afectará la tarea anterior, solo intento comprender qué está sucediendo “en la naturaleza” tanto como sea posible).
Tuvimos un cliente que intentaba restaurar una copia de seguridad (creo que estaba autoalojado y había estado intentando cosas más allá de su nivel de conocimiento ), y tuvimos otro cliente que nos pidió que configuráramos un sitio de staging para fines de desarrollo de plugins personalizados y tomamos una copia de seguridad del alojamiento de CDCK.
En general, el mecanismo de versionado incorporado en los metadatos de copia de seguridad funciona muy bien para determinar de forma proactiva cuándo algo va a fallar o no, pero este tipo de situaciones* son como minas terrestres
(* De hecho, lo único más que se me ocurre que no está cubierto por el versionado de migración es cuando se inyecta una migración con una marca de tiempo más antigua en la principal, pero me desvío)
Puedo ver que el problema ya está resuelto, pero para añadir una experiencia real: Tuve este problema al intentar restaurar una copia de seguridad creada en una instancia alojada de Discourse a un contenedor de desarrollo que había configurado localmente usando Docker como parte de la configuración de un entorno de desarrollo. ¿Parece que el alojamiento de Discourse ejecuta PG 15 pero el entorno de desarrollo es 13?
(No afectará la tarea anterior, solo intento comprender qué está sucediendo “en la naturaleza” tanto como sea posible).
), y tuvimos otro cliente que nos pidió que configuráramos un sitio de staging para fines de desarrollo de plugins personalizados y tomamos una copia de seguridad del alojamiento de CDCK.