Wir versuchen, in den discourse_docker-Images sinnvolle Standardwerte bereitzustellen, aber es ist nicht möglich, jeden denkbaren Anwendungsfall zu berücksichtigen. Du kannst deine Images gerne anpassen, um ältere Versionen beizubehalten, wenn du das bevorzugst.
In gewissem Maße spiegeln die Abhängigkeitsversionen unsere Hosting-Anforderungen wider – wir verwenden das Basisimage intern. Das bedeutet, dass es nicht zu veralten sollte, aber es bedeutet auch, dass wir nur eine begrenzte Anzahl von Konfigurationen warten können.
Das ist eine völlig in Ordnung gehende Methode, wenn du dich damit wohler fühlst.
Wenn die Warnung beim Vorbereiten des Dumps der alten Datenbank generiert wird, ist das kein Grund zur Sorge. Wir starten den Server nur gegen das alte Datenverzeichnis, um pg_dump auszuführen. Wenn der Dump auf dem neuen Server wiederhergestellt wird, werden die Indizes neu erstellt.
Der Grund, warum du dies siehst, ist, dass wir in den letzten Tagen eine neue Version des Basisimages veröffentlicht haben, die von Debian Bookworm auf Trixie aktualisiert und damit die glibc-Version ändert. Auf dem libc-Provider basierende Lokalisierungen (die du wahrscheinlich verwendet hast) sind bei glibc-Updates nicht stabil, sodass das Upgrade-Skript beim Starten eines Postgres-Servers zum Dumpen deiner alten Daten Warnungen wegen Kollatierungsfehlanpassungen anzeigt.
Die Kollatierungsfehlanpassung ist der Hauptgrund, warum wir das Dump-und-Wiederherstellen-Verfahren statt pg_upgrade verwenden. Sobald deine Datenbank C.UTF-8 mit dem builtin-Provider verwendet, werden Upgrades der glibc die Kollatierungen nicht mehr beeinflussen.