Ich wollte mein PG14 Server auf die Version 15 Upgraden.
Das ging nicht, weil meiner Meinung nach die Beschreibung falsch ist. Nur jetzt startet mein PG14 nicht mehr.
2023-02-24 14:56:05.196 CET [704] LOG: PostgreSQL 14.6, compiled by Visual C++ build 1914, 64-bit startet
2023-02-24 14:56:05.199 CET [704] LOG: erwarte Verbindungen auf IPv6-Adresse »::1«, Port 5432
2023-02-24 14:56:05.199 CET [704] LOG: erwarte Verbindungen auf IPv4-Adresse »127.0.0.1«, Port 5432
2023-02-24 14:56:05.208 CET [704] LOG: erwarte Verbindungen auf IPv4-Adresse »192.168.14.14«, Port 5432
2023-02-24 14:56:05.230 CET [1256] LOG: Datenbanksystem wurde am 2023-02-24 14:40:24 CET heruntergefahren
2023-02-24 14:56:05.231 CET [1256] LOG: ungültige Datensatzlänge bei 145/DFC3EEB8: 24 erwartet, 0 erhalten
2023-02-24 14:56:05.231 CET [1256] LOG: ungültiger primärer Checkpoint-Datensatz
2023-02-24 14:56:05.231 CET [1256] PANIK: konnte keinen gültigen Checkpoint-Datensatz finden
2023-02-24 14:56:05.270 CET [704] LOG: Startprozess (PID 1256) wurde durch Ausnahme 0xC0000409 beendet
2023-02-24 14:56:05.270 CET [704] TIPP: Sehen Sie die Beschreibung des Hexadezimalwerts in der C-Include-Datei »ntstatus.h« nach.
2023-02-24 14:56:05.270 CET [704] LOG: Serverstart abgebrochen wegen Startprozessfehler
2023-02-24 14:56:05.298 CET [704] LOG: Datenbanksystem ist heruntergefahren
Die Header Datei gibt es bei mir gar nicht, daher nutzt so eine Meldung auch nicht viel.
Na ja ich habe versucht das was hier steht. Und da den Abschnitt für Windows Users
Da kam bei mehrfachen Probieren und meine Angabe kontrollieren, dass in dem neuen Cluster ein Verzeichnis - glaube pg_upgrade.d/Datei nicht angelegt werden konnte wegen “Permission denied”, was Quatsch ist, denn die Dateien waren nach jedem Versuch da.
Dann hatte ich mir gedacht - OK dann eben nicht, soll von mir aus bis alle Ewigkeit mit V14 laufen. Systemplate vor den Versuchen der Installation/ Upgrade aus der Sicherung geholt. Tja nur wie auch immer hat der Versuch/die Versuche die DB Instanz zerschossen.
Nun ich konnte beide Probleme lösen.
Also, dass PG nicht mehr starten wollte mit pg_resetwal. Und das Update auf Version 15 hat auch geklappt, nach dem ich eine Anleitung gefunden habe die auch funktioniert.
Nach der Offizieller Anleitung habe ich den Ärger gehabt und als ich es repariert habe ging das damit nicht. Vielleicht bin/ war ich aber auch zu unfähig es so umzusetzen.
Unter Vorbehalt (denn es gibt immer die Möglichkeit, dass der Fehler vor der Tastatur saß) würde ich doch behaupten, nach der offizieller Anleitung kann es nicht gehen. Wohl bemerkt - Windows. Bei Linux gehe ich eh seit Jahren nach einer Anleitung die womöglich aus alter offizieller Doku stammte.
Wofür das z.B gut sein sollte verstehe ich nicht
“RUNAS /USER:postgres “CMD.EXE”
SET PATH=%PATH%;C:\Program Files\PostgreSQL\15\bin;”
Das heißt ich muss also erst im System einen User anlegen, denn es sonst nicht gibt.
Ich bin also nach dieser Anleitung vorgegangen Link
Viele Unterschiede zu der Offiziellen sind es nicht aber wohl ausreichend viele, das es bei mir funktioniert hat.
Ich glaube in dem Fall entscheidend waren 2 Punkte - die IP Kommunikation auf “Trust” zu setzen und eben dann bei pg_upgrade den -U postgres mitzugeben.
Vielleicht hängt das ganze aber von kompletter Systemkonfiguration. ab.
Hmm, das musste ich noch nie unter Windows. Der Postgres Service läuft mit dem “Lokalen Systemkonto” und das Datenverzeichnis liegt nicht unter C:\Program Files, sondern ausserhalb. Die Berechtigungen sind so gesetzt, dass mein normaler Benutzer darauf zugreifen darf (das “Lokale Systemkonto” darf das eh, als gibt es kein Problem mit den Zugriffsrechten). Und dann kann ich problemlos pg_upgrade ausführen. Nur das Anlegen des Windows Service mache ich als Administrator.
Grundsätzlich ist es natürlich sicherer, wenn der Service mit einem normalen Benutzer gestartet wird (auch wenn das mittlerweile nicht mehr so wichtig ist, weil Postgres alle “höheren” Privilegien beim Start “abgibt”).
Also ist das Anlegen eines postgres Benutzers sicher keine schlechte Idee. Dann muss aber pg_upgrade auch als dieser Benutzer gestartet werden.
Das mit dem TRUST mache ich auch immer bevor ich pg_upgrade starte, nach dem Upgrade wird das wieder zurückgesetzt.
Das ist nicht notwendig, wenn der postgresDatenbankbenutzer in beiden Instanzen das gleiche Passwort hat und man vorher die Umgebungsvariable PGPASSWORD setzt.
Wichtig ist auch, dass das neue und das alte Datenverzeichnis die gleichen Berechtigungen haben. Am einfachsten ist das zu erreichen, wenn das initdb immer mit dem gleichen Windows Benutzer ausgeführt wird (in Deinem Fall also der PostgresWindowsbenutzer)
Ich mache Installation und Upgrade immer auf der Kommandozeile. Den Installer mag ich nicht (nicht zuletzt deswegen weil er immer versucht das Datenverzeichnis unter c:\Program Files anzulegen was unter Windows einfach völlig dämlich ist)
Jetzt hast Du mich aber verwirrt.
Ich hatte es so verstanden, dass Du auf mein “und eben dann bei pg_upgrade den -U postgres mitzugeben.” mit " Das ist nicht notwendig, wenn der postgresDatenbank benutzer in beiden Instanzen das gleiche Passwort hat und man vorher die Umgebungsvariable PGPASSWORD setzt."
Das “nicht notwendig” bezog sich auf das Setzen des “trust” Modus. Das Ändern auf trust it nicht notwendig wenn der postgres User in beiden Instanzen das gleiche Passwort hat - und dieses über PGPASSWORD gesetzt wurde.