Nein, Sir, kein Problem. Danke für die Info
In meinem Fall lag es daran, dass ich scram-sha-256 und nicht trust als Authentifizierungsmechanismus hatte.
Denn scram-sha-256 erfordert einen physischen Benutzer.
Sie können das wahrscheinlich umgehen, indem Sie eine Benutzerzuordnung in pg_ident.conf erstellen, aber ich bin mir nicht sicher, wie.
Wenn Sie mit „physischem Benutzer“ einen „Unix-Systembenutzer“ meinen, dann nein, scram-sha-256 erfordert keinen solchen Benutzer im System. Die Methode peer erfordert einen Systembenutzer, und trust ist generell eine schlechte Idee, wenn Sie einen entfernten Datenbankserver verwenden.
Müssen wir zusätzlich zum bestehenden Prozess Folgendes einbeziehen?
CREATE EXTENSION vector;
da ich diese Erweiterung im discourse_docker postgres-Template sehe?
Das wird vom Discourse AI Core Plugin verwendet, daher benötigen Sie dieses, wenn Sie es verwenden.
Ich erinnere mich nicht, dieses Plugin aktiviert zu haben. Tatsächlich habe ich gerade überprüft, dass es deaktiviert ist. Aber kürzlich, als ich das Image neu erstellt habe, als der letzte Commit über diesen Commit hinausging – GitHub - discourse/discourse at 0eab7daea450e1d7e416c46a23aaaf95687d4855 – begann rake db:migrate zu fehlschlagen. Als ich den Commit direkt vor dem obigen zum Bootstrapping verwendete, funktionierte es weiterhin.
Jetzt, da ich diese Erweiterung aktiviert habe, funktionieren Commits danach ohne Probleme.
Aber jetzt ist das KI-Plugin im Kern, also brauchen Sie die Erweiterung, unabhängig davon, ob Sie das KI-Plugin verwenden (oder es explizit entfernen), richtig?
Das stimmt, da Migrationen unabhängig davon ausgeführt werden, ob das Plugin aktiviert ist.