Bugfix Postgres 9.6.3/9.6.4

Hallo,
ich bin etwas verwirrt:

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? :confused:
Wenn ich jetzt schon wieder wegen eines Updates hier alles lahmlegen muss, darf ich mich warm anziehen … :frowning:

Grüße

Micha

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. :wink:

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 …

“Das einspielen ist nicht das Problem, sondern die vielen Anlagen die bei uns nach jeder Unterbrechung neu zu starten sind.”

Du könntest pgbouncer vorschalten und bei solchen Maintenance-Arbeiten mit PAUSE und RESUME arbeiten, dann ist das transparent für die Anwendung.

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.

Nun ja, es gibt ja auch noch Replikation. Und repmgr, mit dem kannst Du einen geplanten Switchover sehr einfach machen.

Ich sollte Euch wohl mal ein Consulting-Angebot machen …

Ich sollte Euch wohl mal ein Consulting-Angebot machen …
Hört sich gut an, werde ich vorschlagen.