ich habe vor kurzem meine Datenbank von 8.3 auf 8.4 migriert.
Seither habe ich öffters Probleme, dass meine Anwendung während dem Betrieb die Verbindung zur DB verliert.
Obwohl das Programm alle ca. 30 sec eine Select abfrage ausführt.
Als Fehlermeldung bekomme ich folgendes:
[I]Eine vorhandene Verbindung wurde vom Remotehost geschlossen[/I]
In der PG Logs viel mir dabei immer folgender Eintrag auf:
CESTWARNUNG: pgstat wait timeout
Wurde bei 8.4 irgendetwas geänder bez. einem Timeout etc?
Habe mir die Posts mal angeschaut.
Aber dennoch hilft mir das leider nicht weitr.
Negestartet habe ich den PC seit der Migration mehrmals.
Ich habe nun mal ANalyze und Vaccuum durchlaufen lassen (manuell). evtl. bringt das etwas.
dieses problem habe ich auch wenn ich pg8.4 als vista-dienst laufen lasse - von 8.3 ist mir das nicht bekannt … noch habe ich keine loesung dafuer gefunden … (außer pg in einer vm unter einem linux laufen zu lassen - aber das ist auch nur ne frickellösung die keine wirkliche antwort liefert)
das läßt sich auch mit pgadminIII beobachten … man kann sich mit einer DB verbinden - aber so ziemlich jede abfrage scheitert damit, dass der client-prozess (dienst) abbricht (abnormal abort) leider bin ich noch nicht dazu gekommen logs zu studieren
wenn du also ne idee hast worans lag - ruhig her damit
Leider habe ich noch keine idee.
Ich habe die PG8.4 auf zwei verschiedenen Rechnern (aber unterschiedliche Tabellen) auf dem 2. Rechner tritt dieses Problem nicht auf. Die Installation habe ich bei beiden genau gleich gemacht.
Beide laufen als Dienst (ANmeldung: “Lokales Systemkonto”).
Die conifg Datei ist bei beiden 100% identisch.
Das einzigste was mir aufgefallen ist (ob es damit zu tun hat weis ich nicht), ist dass in dem Verzeichniss pgstat_log_tmp eine Datei namens pgstat.stat vorhanden ist.
Diese Datei ist bei dem funktionierenden Rechner rund 20kb groß und bei dem Rechner mit den Problemen ist diese 50kb groß.
Ansonsten habe ich leider keine weiteren Logeinträge.
Aber ich werde mal den Loglevel etwas erhöhen. Evtl. sehe ich damit mehr.
kannst du dich erinnern, dass du auf dem rechner wo das problem auftritt - vielleicht vorher schonmal eine pg8.4 version installiert war? also dass es vielleicht an irgendwelchen ueberresten einer frueheren installation liegt?
Des weiteren habe ich mittels perfmon die CPU Zeit etc. aufzeichnen lassen, und festgestellt, dass zu dieser Zeit die CPU last auf 100% war. Wodurch ist noch nicht klar.
Dennoch sollte so etwas auch bei 100%iger CPU last nicht auftreten.
Nun ja, wenn aufgrund hirnampotierter Schadsoftware die DB an der Arbeit gehindert wird, was soll sie da sonst tun? Deine Daten einem Zufallsgenerator überlassen?
Herr Doktor, immer wenn ich mir mit dem Hammer auf die Finger haue, tut es weh. Bitte helfen Sie mir.
02809 /*
02810 * If we've been told to shut down, we exit as soon as there are no
02811 * remaining children. If there was a crash, cleanup will occur at the
02812 * next startup. (Before PostgreSQL 8.3, we tried to recover from the
02813 * crash before exiting, but that seems unwise if we are quitting because
02814 * we got SIGTERM from init --- there may well not be time for recovery
02815 * before init decides to SIGKILL us.)
02816 *
02817 * Note that the syslogger continues to run. It will exit when it sees
02818 * EOF on its input pipe, which happens when there are no more upstream
02819 * processes.
02820 */
02821 if (Shutdown > NoShutdown && pmState == PM_NO_CHILDREN)
02822 {
02823 if (FatalError)
02824 {
02825 ereport(LOG, (errmsg("abnormal database system shutdown")));
02826 ExitPostmaster(1);
02827 }
02828 else
02829 {
02830 /*
02831 * Terminate backup mode to avoid recovery after a clean fast
02832 * shutdown.
[color="#ff0000"]02833 */
02834 CancelBackup();
02835 [/color]
02836 /* Normal exit from the postmaster is here */
02837 ExitPostmaster(0);
02838 }
02839 }
letzteres sind aber eher vermutungen (stellen) - habe gerade den code von 8.4 nicht da um dort mal drin zu suchen …
2009-08-20 16:39:11 CESTLOG: Autovacuum-Launcher startet
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:41:42 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:43:42 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:45:12 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:46:42 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:48:42 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:50:13 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
2009-08-20 16:51:13 CESTWARNUNG: worker took too long to start; cancelled
FATAL: could not reattach to shared memory (key=244, addr=021D0000): 487
kommt mir irgendwie bekannt vor … hmm
hab mal autovacuum abgeschaltet - prompt gehts - keine abbrueche mehr …
nein das habe ich noch nicht gesehen / gelesen - danke … mal schauen - bin jetzt 3 wochen urlauben bei mir ist das thema gerade nicht so akut - aber ich habe es auch hier auf nem bastelsystem und es ist einfach gut zu wissen womit man es zu tun hat - immerhin wollen vielleicht kunden das auf nem vista auch installieren …
ach ja … ich habe hier ein vista64 (ultimate) … der OP hatte ein vista ??? irgendwas ?
mir faellt halt auf, dass der fehler NICHT mehr auftritt, wenn man autovacuum abschaltet - dass shared-memory nicht mehr retatched werden kann - so glaubte ich bis eben - liegt daran, dass irgendein client-prozess wegen irgendeinem problem abstuerzt … bin gerade am lesen … um zu sehen “wieviel” die schon wissen … von dem absturz steht nix im log - es sei denn der client-prozess selbst stellt ein problem fest (kann man in den beispielen hier auch sehen) und leitet seinen not-tod -> “shutdown” ein.
es ist ja durchaus denkbar, dass das retatch problem garkeines ist - sondern nur die folge eines anderen problems