Ich hatte erst einen Tag vor der Version 9.6.4 auf die Version 9.6.3 aktualisiert.
Dazu hatte ich für alle Datenbanken die im changelog beschriebene Funktion für alle DBs ausgeführt.
Was ist jetzt an der im changelog beschriebenen Funktion anders?
Leider ist die alte Version von 9.6.3 nicht mehr zu finden.
Ich lasse keine User ohne Passwort zu.
Die libpq + client habe ich auf dem Datenbankserver schon auf 9.6.4 aktualisiert, den DB-Server noch nicht.
Auf den Clientrechnern gibt es aber viele sehr alte libpqs …
In den Kommentaren im heise forum zum oberen link herrscht auch nur Konfusion!
Welche Risiken gehe ich jetzt mit der Version 9.6.3 + Fix aus der 9.6.3 ein?
Wenn ich jetzt schon wieder wegen eines Updates hier alles lahmlegen muss, darf ich mich warm anziehen …
Alte Funktion (direkt aus der gefixten 9.6.3er DB gelesen):
CREATE OR REPLACE VIEW pg_user_mappings AS
SELECT u.oid AS umid,
s.oid AS srvid,
s.srvname,
u.umuser,
CASE
WHEN u.umuser = 0::oid THEN 'public'::name
ELSE a.rolname
END AS usename,
CASE
WHEN u.umuser <> 0::oid AND a.rolname = "current_user"() OR u.umuser = 0::oid AND pg_has_role(s.srvowner, 'USAGE'::text) OR ( SELECT pg_authid.rolsuper
FROM pg_authid
WHERE pg_authid.rolname = "current_user"()) THEN u.umoptions
ELSE NULL::text[]
END AS umoptions
FROM pg_user_mapping u
LEFT JOIN pg_authid a ON a.oid = u.umuser
JOIN pg_foreign_server s ON u.umserver = s.oid;
Neue Funktion (aus changelog 9.6.4):
CREATE OR REPLACE VIEW pg_user_mappings AS
SELECT
U.oid AS umid,
S.oid AS srvid,
S.srvname AS srvname,
U.umuser AS umuser,
CASE WHEN U.umuser = 0 THEN
'public'
ELSE
A.rolname
END AS usename,
CASE WHEN (U.umuser <> 0 AND A.rolname = current_user
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
THEN U.umoptions
ELSE NULL END AS umoptions
FROM pg_user_mapping U
LEFT JOIN pg_authid A ON (A.oid = U.umuser)
JOIN pg_foreign_server S ON (U.umserver = S.oid);
Ok, da hat sich etwas mit der Klammer geändert, aber welche Konsequenz hat dieser Unterschied?
Was genau meinst Du mit “Dazu hatte ich für alle Datenbanken die im changelog beschriebene Funktion für alle DBs ausgeführt.”?
Meinst Du mit “Leider ist die alte Version von 9.6.3 nicht mehr zu finden.” das Changelog der 9.6.3?
Ich denke, den Server auf die aktuelle 9.6.4 upzudaten sollte kein so großer Aufwand sein, einfach Pakete installieren und neu starten. Es sind ja doch eine ganze Latte von Fixes drin - wie immer.
PS.: die Tage, wann neue Releases rauskommen, sind relativ fix und lange vorher bekannt. Das nächste kommt am 9.11. und das übernächste am 8. Februar 2018. (vorausgesetzt, es ist kein ganz akutes nötig, was eher sehr selten ist). Das kann man also in seine Planung einbeziehen.
In dem Changelog zur 9.6.3er Version stand ursprünglich auch eine Anleitung mit “CREATE OR REPLACE VIEW pg_user_mappings AS”.
Diese wurde beim erscheinen von 9.6.4 entfernt …
Das einspielen ist nicht das Problem, sondern die vielen Anlagen die bei uns nach jeder Unterbrechung neu zu starten sind.
Diese arbeiten hier 24/7, da gibt es Langzeitmessungen die mehrere Tage dauern, die aber nicht alle zu gleichen Zeiten gestartet/gestoppt werden.
Eigentlich kann ich da fast nur zu Weihnachten und zu Ostern eingreifen.
Ostern hatte es diesmal nicht geklappt und das letzte Update war aus der Not:
Tägliches: “FATAL: das Datenbanksystem ist im Wiederherstellungsmodus” hatte mich dazu motiviert den Server auszutauschen.
Na der 09.11. hört sich doch gut zur nächsten Inventur an …
Danke, gute Idee! Werde ich mir mal durch den Kopf gehen lassen.
Ist aber auch nur für sehr kurze Unterbrechungen geeignet, da die Anwendungen innerhalb einer bestimmten Zeit ihre Daten loswerden müssen, sonst passt die Messung nicht zu bestimmten externen Ereignissen (Timeout).
Ansonsten müssen wir die Anwendungen mit Puffern versehen.
Ist halt eine Haufen Arbeit und nicht in ein paar Tagen umzubauen.