Etherpad-lite: Behandeln Sie die nicht verfügbare Datenbankverbindung ordnungsgemäß

+1 das.

https://github.com/ether/ueberDB für unsere Datenbankabstraktion übrigens. Dies ist nicht nur ein PG-Problem, sondern betrifft alle DBs.

Ich würde eine PR akzeptieren, ich bin mir nicht sicher, wo ich sie am besten reparieren kann, ich denke, wahrscheinlich muss ueberdb ausgeben, wenn die DB verloren geht.

Sie möchten wahrscheinlich nie eine Nachricht an den Client senden, aber vielleicht nur einen generischen Fehler an den Client, löschen Sie den Fehler in den Backend-Protokollen und den Cache im Speicher, bis die Datenbank wiederhergestellt ist. Das Problem ist, dass der Cache im Speicher bis zur Wiederherstellung der Datenbank wahrscheinlich eine neue Logik erfordert für jeden Datenbank-Connector, was eine größere Aufgabe sein kann, als wir Zeit haben.

Es ist erwähnenswert, dass Etherpad so konzipiert ist, dass es bei Fehlern stirbt. Wir versuchen, die Dinge nicht am Leben zu erhalten, sondern scheitern. Es war eine frühe Designentscheidung, die sich ziemlich ausgezahlt hat, da sie uns gezwungen hat, Etherpad stabil zu machen (ish). Die Startup-Skripte von Etherpad werden versuchen, Etherpad neu zu starten und die DB-Konnektivität wiederherzustellen Ich habe das Gefühl, wenn die Datenbank weg ist, sollte es sehr klar sein, dass Etherpad ausfällt, weil eine Datenbank weg ist.

Ich denke nicht, dass das ein Verbindungsproblem ist. column <name> is of type jsonb but expression is of type text scheint eine ziemlich häufige Sache zu sein, die passiert, wenn die Middleware Abfrageparameter auf unerwartete Weise einrichtet. Die Spalte wird als JSONB erstellt, aber wenn der Abfragegenerator etwas wie JSON.encode verwendet, wird der Typ als Zeichenfolge abgeleitet und der Parameter wird als Typ TEXT oder VARCHAR ("Zeichen variieren" in Fehlermeldungen) gebunden.
Anscheinend kann das auch ein Problem sein, wenn Strings oder Arrays anstelle von Objekten gespeichert werden, die sie enthalten?

Zufälliges Beispiel, das über Google gefunden wurde und nicht mit diesem Projekt in Zusammenhang steht: https://github.com/jeremydaly/data-api-client/issues/27#issuecomment -584701957

Oh, überprüfen Sie die zurückgesetzten Commits. Vor einiger Zeit gab es einen schlechten pg-Commit, der, glaube ich, damit zusammenhing.

Mir ist gerade aufgefallen - es sieht so aus, als hätten wir die CREATE TABLE mit jsonb darin, die Version in node_modules ist nur text bereits. FWIW haben wir auch ueberdb_insert_or_update() mit Textargument, kein überladenes übrig...

Nur um sicher zu gehen, bevor ich es umwandele, ist Text das, was er sein soll (vorerst)?

Nach der Konvertierung in Text scheint alles zu funktionieren:

ALTER TABLE storage ALTER COLUMN value TYPE text USING value::text;