Verbindung wird getrennt

Hallo zusammen,

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?

Danke im voraus.

Grüße
Matrix-NTN

Hilft Re: [BUGS] pgstat wait timeout weiter?

Andreas

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.

Grüße
Matrix

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 :slight_smile:

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.

Grüße
Matrix-NTN

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?

ALso auf beiden Rechner war zuvor Postgresql 8.3.7 installiert.
Die 8.4, welche aktuell installiert ist, wurde bei beiden das erstemal installiert.

Grüße
Matrix-NTN

Hallo,

ich habe gestern die Protokolle noch auf maximum gestellt (debug5 etc.).
Heute konnte ich in den protokollen folgendes entnehmen:

CESTWARNUNG:  01000: pgstat wait timeout
CESTORT:  backend_read_statsfile, .\src\backend\postmaster\pgstat.c:3434

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.

Grüße
Matrix-NTN

Ich tippe ja auf irgendwas in Richting Bakterienscanner oder Tischbrandschutzmauer.

Andreas

Ich tippe ja auf irgendwas in Richting Bakterienscanner oder Tischbrandschutzmauer.

Das mag ja wohl sein, dennoch darf dann die Datenbank nicht einfach die Verbindungen trennen!

Grüße
Matrix-NTN

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.

Andreas

hier das steht in meinem log …

2009-08-17 21:00:19 CESTLOG:  Datenbanksystem wurde am 2009-08-17 20:50:05 CEST heruntergefahren
2009-08-17 21:00:20 CESTFATAL:  das Datenbanksystem startet
2009-08-17 21:00:20 CESTLOG:  Datenbanksystem ist bereit um Verbindungen anzunehmen
2009-08-17 21:00:20 CESTLOG:  Autovacuum-Launcher startet
[color="Blue"]2009-08-17 21:31:03 CESTLOG:  schnelles Herunterfahren verlangt[/color]
2009-08-17 21:31:03 CESTLOG:  etwaige aktive Transaktionen werden abgebrochen
2009-08-17 21:31:03 CESTLOG:  Autovacuum-Launcher fährt herunter
2009-08-17 21:31:03 CESTLOG:  fahre herunter
2009-08-17 21:31:03 CESTLOG:  Datenbanksystem ist heruntergefahren

hier nochmal anders

2009-08-18 19:46:28 CESTLOG:  Datenbanksystem wurde am 2009-08-17 21:31:03 CEST heruntergefahren
2009-08-18 19:46:28 CESTLOG:  Datenbanksystem ist bereit um Verbindungen anzunehmen
2009-08-18 19:46:28 CESTLOG:  Autovacuum-Launcher startet
[color="Blue"]2009-08-18 19:46:28 CESTLOG:  verfälschte Datei pgstat.stat[/color]
[color="#0000ff"]2009-08-18 20:37:12 CESTLOG:  schnelles Herunterfahren verlangt[/color]
2009-08-18 20:37:12 CESTLOG:  etwaige aktive Transaktionen werden abgebrochen
2009-08-18 20:37:12 CESTLOG:  Autovacuum-Launcher fährt herunter
2009-08-18 20:37:12 CESTLOG:  fahre herunter
2009-08-18 20:37:12 CESTLOG:  Datenbanksystem ist heruntergefahren

hier der passende code des postmasters:
http://doxygen.postgresql.org/postmaster_8c-source.html

-#: postmaster/pgstat.c:2614 postmaster/pgstat.c:2636 postmaster/pgstat.c:2650
-#: postmaster/pgstat.c:2702 postmaster/pgstat.c:2719 postmaster/pgstat.c:2736
-#: postmaster/pgstat.c:2769 postmaster/pgstat.c:2776 postmaster/pgstat.c:2788
[color="Red"][B]-#: postmaster/pgstat.c:2833[/B][/color]
-msgid "corrupted pgstat.stat file"
-msgstr "verfälschte Datei pgstat.stat"
+#: utils/misc/guc.c:1553



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 …

also ich habe 9 potentielle stellen in der pgstat.c gefunden, die den fehler ausgeben …

und soweit ich das sehe spielt sich das alles in dieser funktion ab

/* ----------
 * pgstat_read_statsfile() -
 *
 *	Reads in an existing statistics collector file and initializes the
 *	databases' hash table (whose entries point to the tables' hash tables).
 * ----------
 */
static HTAB *
pgstat_read_statsfile(Oid onlydb, bool permanent)

ob das aber die ursaechliche ursache des ganzen ist kann man ja auch nicht erkennen …

hmm … ich habe gerade mal alle logs geloescht und die pgstat.stat auch … nun gehts wieder… ?!"§!"§!= … also backend stürtz nimmr ab …

vorhin hatte ich bereits diese pgstat.stat geloescht … brachte aber scheinbar nix …

seltsam - werds beobachten

schalte mal auf dem fehlerhaften system (auto)vacuum ab …

und dann probier nochmal obs geht …

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 …

Autovacuum ist immernoch OFF … und immernoch tuts tadellos -> keine Abbrueche …

scheint so, als waere da ein gewisser Fehler aus einer Beta noch nicht wirklich behoben …

Obs ein grundsätzliches problem bei konkurrierenden zugriffen auf die daten gib (mehrere gleichzeitig arbeitende clients) weiss ich noch nicht

Hi,

hast du das hier gesehen:
Help us test a patch for the Win32 shared memory issue - Magnus Hagander’s PostgreSQL blog

Diskussion findest du im Archiv mit folgendem Titel:
“could not reattach to shared memory” on Windows
Freundliche Grüße
hkocam

nein das habe ich noch nicht gesehen / gelesen - danke … mal schauen - bin jetzt 3 wochen urlauben :slight_smile: 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 :wink: 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

wie immer unter win wird pg als win32-Anwendung ausgeführt