Nach Upgradeversuch startet PG14 unter Windows nicht mehr

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.

was genau hast Du wie gemacht? Die Doku enthält eine umfangreiche Anleitung, welche Wege es gibt:

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.

War es die offizielle, die ich gezeigt hatte, oder eine andere? Enthält die offizielle Fehler? Falls ja: welche?

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 postgres Datenbankbenutzer 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 Postgres Windowsbenutzer)

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)

Richtig und damit ist der Eintrag in der Doku “runas /user:postgres” falsch

Woher soll dann das pg_upgrade wissen welche User PG-Admin ist?

Das definiert man mit dem Parameter -U (--username)

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 postgres Datenbank benutzer in beiden Instanzen das gleiche Passwort hat und man vorher die Umgebungsvariable PGPASSWORD setzt."

Damit war aber wohl was anderes gemeint.

Sorry.

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.

Dieses Thema wurde nach 60 Tagen automatisch geschlossen. Es sind keine neuen Antworten mehr erlaubt.