Entschuldige bitte, dass ich das Thema erneut aufgreife. Ich habe eine sehr seltsame Fehlermeldung erhalten:
discourse=# REINDEX SCHEMA CONCURRENTLY public;
ERROR: could not create unique index "index_tags_on_name_ccnew"
DETAIL: Key (name)=(chronicillness) is duplicated.
Ich gehe davon aus, dass sich das Problem mit der oben von @riking vorgeschlagenen Lösung beheben lässt, aber ich kann nicht herausfinden, wie ich die Syntax an meinen Fall anpassen soll. 
Siehe:
https://twitter.com/petervgeoghegan/status/1264325695997538304?s=20
https://twitter.com/petervgeoghegan/status/1264404749899534338?s=20
Wenn Sie diesen Fehler sehen, haben Sie zwei Möglichkeiten:
Sie können das Problem umgehen … in diesem Fall enthält die Tabelle tags einen doppelten Eintrag mit dem Namen chronicillness.
Führen Sie eine Abfrage im Data Explorer durch, um die Zeilen zu suchen: select * from tags where name = 'chronicillness.
Löschen Sie den Duplikat-Eintrag:
./launcher enter app
rails c
Tag.find_by(id: ID_YOU_FOUND_IN_DATA_EXPLORER).destroy
Falls Sie eine Sicherungskopie Ihrer Datenbank haben und Details, die Sie mit Peter teilen möchten … teilen Sie diese entweder privat oder auf der PG-Mailingliste mit Peter.
Also ich habe ein von Discourse generiertes Backup von PostgreSQL 10. Ist das hilfreich? Kann ich einfach den PostgreSQL-Teil aus dem Archiv extrahieren und senden?
Ich bin mir nicht sicher… Was Peter wahrscheinlich braucht, ist, dass du deine Datenbank stoppst und den gesamten Inhalt des Ordners kopierst, der die Datenbank enthält.
Der beste Weg, das herauszufinden, ist, ihm eine E-Mail zu schreiben.
Klar, ich schreibe ihm eine E-Mail, um das herauszufinden 
NB: Das habe ich erhalten, als ich die SQL-Abfrage im Data Explorer ausgeführt habe:
| id | name | topic_count | created_at | updated_at | pm_topic_count | target_tag |
|---|---|---|---|---|---|---|
| 1710 | chronicillness | 2 | 2019-12-03T17:49:17.395Z | 2019-12-03T17:49:17.395Z | 0 | NULL |
Wird das hier ausreichen?
Tag.find_by(id: 1710).destroy
oh … der Index liegt auf LOWER(name)
Führe die Abfrage wie folgt aus:
select * from tags where name ilike 'chronicillness'
Du solltest 2 Zeilen erhalten.
select * from tags where name ilike 'chronicillness'
| id | name | topic_count | created_at | updated_at | pm_topic_count | target_tag |
|---|---|---|---|---|---|---|
| 329 | chronicillness | 12 | 2017-08-22T00:17:38.824Z | 2017-08-22T00:17:38.824Z | 0 | NULL |
| 1710 | chronicillness | 2 | 2019-12-03T17:49:17.395Z | 2019-12-03T17:49:17.395Z | 0 | NULL |
Könnte es ein - zwischen den Tag-Namen sein?
Ich sehe hier zwei Tags: chronicillness und chronic-illness.
Na dann ist das das Problem … Ich schätze, du löschst 1710. Danach werden zwei Themen dieses Tag vermissen.
#<Tag:0x00005607bb92cf48
id: 1710,
name: "chronicillness",
topic_count: 0,
created_at: Tue, 03 Dec 2019 17:49:17 UTC +00:00,
updated_at: Tue, 03 Dec 2019 17:49:17 UTC +00:00,
pm_topic_count: 0,
target_tag_id: nil>
Ich habe das Gefühl, es war ein Zwerg, der mit nichts in Verbindung stand?
Das Löschen des Tags hat noch mehr Dinge gebracht!
discourse=# REINDEX SCHEMA CONCURRENTLY public;
WARNING: cannot reindex invalid index "public.tags_pkey_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_name_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_lower_name_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "pg_toast.pg_toast_309322_index_ccnew" concurrently, skipping
ERROR: could not create unique index "index_tags_on_name_ccnew1"
DETAIL: Key (name)=(time-management) is duplicated.
Gleiche Lösung Du musst den Vorgang wiederholen.
Das habe ich gemacht. Aber sind diese Warnungen in Ordnung? Muss ich mir darum keine Sorgen machen, oder?
Ja, alle Warnungen sind korrekt. Sie haben einen beschädigten Index, der zuerst repariert werden muss.
Also sind alle Kopien jetzt verschwunden und ich habe nur noch diese Warnungen beim Neuindizieren:
discourse=# REINDEX SCHEMA CONCURRENTLY public;
WARNING: cannot reindex invalid index "public.tags_pkey_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_name_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_lower_name_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "public.tags_pkey_ccnew1" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_name_ccnew1" concurrently, skipping
WARNING: cannot reindex invalid index "public.index_tags_on_lower_name_ccnew1" concurrently, skipping
WARNING: cannot reindex invalid index "pg_toast.pg_toast_309322_index_ccnew" concurrently, skipping
WARNING: cannot reindex invalid index "pg_toast.pg_toast_309322_index_ccnew1" concurrently, skipping
REINDEX
Gibt es etwas, das getan werden sollte, um diese Warnungen loszuwerden, oder müssen wir damit leben?
Das ist für mich verwirrend … wir haben keine Indexnamen, die mit ccnew enden … hast du diese manuell erstellt?
Ich denke, diese werden bei der Migration von PostgreSQL 10 auf 12 verwendet, da ich sie bei fast jedem Benutzer gesehen habe, dessen Indizes Probleme hatten. Z. B.:
https://meta.discourse.org/t/postgresql-12-update/151236/208?u=itsbhanusharma
https://meta.discourse.org/t/postgresql-12-update/151236/237?u=itsbhanusharma
EDIT: stammt direkt von PostgreSQL
Die empfohlene Wiederherstellungsmethode in solchen Fällen besteht darin, den ungültigen Index zu löschen und
REINDEX CONCURRENTLYerneut auszuführen. Der während der Verarbeitung erstellte parallele Index hat einen Namen, der mit dem Suffixccnewendet, oderccold, falls es sich um eine alte Indexdefinition handelt, die wir nicht löschen konnten. Ungültige Indizes können mitDROP INDEXgelöscht werden, einschließlich ungültiger Toast-Indizes.
Ouch … sind die richtigen Indizes auch bereits auf der Tabelle vorhanden?
Du kannst die Indizes auf der Tabelle meines Wissens nach mit dem Data Explorer auflisten.
Wenn die richtigen vorhanden sind, kannst du diese problematischen Indizes einfach entfernen.
Lass mich das überprüfen. Ich gebe dir Bescheid.
Die Indizes scheinen also zu existieren.
Für problematische Indizes existieren auch Duplikate mit dem angefügten ccnew oder ccnew1.
Ich weiß nicht, wie man prüfen kann, ob diese Indizes gültig sind, aber wenn das Löschen eine Option ist, bin ich gerne bereit, sie zu löschen und neu zu indizieren.
EDIT: Funktioniert DROP INDEX wie hier vorgeschlagen?
Ja, löscht sie alle … keine Ahnung, wie sie dorthin gekommen sind … DROP INDEX ist das, was du verwenden solltest.
./launcher enter app
rails c
DB.exec('drop index tags_pkey_ccnew1')