Per impostazione predefinita, quando si verifica l’unicità su una tupla ai fini dell’applicazione di un indice univoco, PostgreSQL considera i NULL come valori distinti. A causa di ciò, potremmo avere erroneamente più voci con { identifier: "rails_env", target: nil } create a causa di race condition. Ciò causerebbe quindi errori a runtime.
Come si risolve?
Elimina l’indice esistente e ricrealo con l’opzione NULLS NOT DISTINCT.
Problema
Tuttavia, NULLS NOT DISTINCT è stato introdotto in Postgres 15 beta2. La versione corrente di Postgres in un’installazione standard è Postgres 13 e non supporta questa funzionalità.
Conseguenze
questa modifica non avrà alcun effetto su PG13 poiché NULLS NOT DISTINCT verrà ignorato (fonte)
il tentativo di ripristinare un backup da un server PG15 a un server PG13 fallirà con il seguente errore
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'
(linea 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 Sembra che dobbiamo annullare la migrazione e riconsiderare un’altra soluzione. Questo probabilmente causa errori nelle installazioni self-hosted.
Beh, non posso parlare per gli altri e non so se sono veramente rappresentativo (probabilmente no), ma l’ho incontrato due volte in 3 giorni dopo che quella modifica è stata apportata…
Quindi un workaround (e un ripristino!) sarebbe molto apprezzato.
Ora che abbiamo la soluzione temporanea, che dovrebbe funzionare anche su PG15, dovremmo essere in grado di rimuovere NULLS NOT DISTINCT.
Per pura curiosità, cosa stavi facendo che ha reso necessario ripristinare un backup di PG15 su PG13? (Non influenzerà l’attività sopra, sto solo cercando di capire il più possibile cosa succede “sul campo”.)
Abbiamo avuto un cliente che stava tentando di ripristinare un backup (penso che fosse self-hosted e avesse provato cose al di là del suo livello di conoscenza ), e abbiamo avuto un altro cliente che ci ha chiesto di impostare un sito di staging per scopi di sviluppo di plugin personalizzati e abbiamo preso un backup dall’hosting CDCK.
In generale, il meccanismo di versioning integrato nei metadati di backup funziona molto bene nel determinare in modo proattivo quando qualcosa sta per esplodere o meno, ma questo tipo di situazioni* sono come mine antiuomo
(* In realtà, l’unica altra cosa che mi viene in mente che non è coperta dal versioning delle migrazioni è quando una migrazione con un timestamp più vecchio viene iniettata nel main, ma divago)
Posso vedere che il problema è già stato risolto, ma per aggiungere un’esperienza “in the wild”: ho riscontrato questo problema cercando di ripristinare un backup creato su un’istanza ospitata da Discourse in un container di sviluppo che avevo configurato localmente utilizzando Docker come parte della configurazione di un ambiente di sviluppo. Sembra che l’hosting di Discourse esegua PG 15 ma l’ambiente di sviluppo sia 13?
(Non influenzerà l’attività sopra, sto solo cercando di capire il più possibile cosa succede “sul campo”.)
), e abbiamo avuto un altro cliente che ci ha chiesto di impostare un sito di staging per scopi di sviluppo di plugin personalizzati e abbiamo preso un backup dall’hosting CDCK.