Hallo,
ich habe von einigen Tagen ein update von pgAdmin4 2.1 auf 3.0 vorgenommen und bis heute damit auch gut gearbeitet. Heute ist mir die Seite im Browser abgestürzt und seitdem kann ich keine Verbindung zur Datenbank mehr herstellen. Es erscheint immer nur “die Verbindung zum Server wurde unterbrochen”. Ich habe den PGAdmin auch schon deinstalliert und nochmals neu installiert, jedoch ohne Erfolg.
Bitte, was kann ich tun, um dieses Problem zu lösen?
läuft denn die DB? Was kommt da an Fehlern?
Vielen Dank für die schnelle Reaktion.
Leider kann ich auf die Datenbank auch mit ODBC nicht mehr zugreifen und das Problem wird recht ernst.
begonnen hat das ganze mit
FATAL: password authentication failed for user “postgres”
DETAIL: Password does not match for user “postgres”.
Connection matched pg_hba.conf line 87: “host all all 111.20.333.0/23 md5”
An dem Passwort hat jedoch niemand etwas geändert, ich war ja auch schon angemeldet.
Eine Anmeldung mit trust statt md5 in der betreffenden Zeile brachte leider keinen Erfolg.
Danach erscheint immer wieder die folgende Meldung, diese Tabelle existiert nicht, aber die Anwendung will offensichtlich darauf zugreifen.
ERROR: relation “meine_tabelle” does not exist at character 42
STATEMENT: Select place_of_statistic_reporting from meine_tabelle;
Kann der x-fachen Versuch diesen Befehl auszuführen die Ursache sein? Denn nach ca. 4h kommt die Meldung
ERROR: relation “msysconf” does not exist at character 28
STATEMENT: SELECT Config, nValue FROM MSysConf
<2018-05-25 14:45:04 CEST postgres postgres pgAdmin 4 - DB:postgres 127.0.0.1(61757) 0 > LOG: could not receive data from client: unrecognized winsock error 10054
TopMemoryContext: 229328 total in 8 blocks; 56512 free (33 chunks); 172816 used
Statistics snapshot: 0 total in 0 blocks; 0 free (0 chunks); 0 used
Record information cache: 24576 total in 2 blocks; 15072 free (5 chunks); 9504 used
TopTransactionContext: 8192 total in 1 blocks; 7960 free (2 chunks); 232 used
Type information cache: 24472 total in 2 blocks; 2840 free (0 chunks); 21632 used
TableSpace cache: 8192 total in 1 blocks; 2312 free (0 chunks); 5880 used
Operator lookup cache: 24576 total in 2 blocks; 10976 free (5 chunks); 13600 used
MessageContext: 262144 total in 6 blocks; 124328 free (4 chunks); 137816 used
Operator class cache: 8192 total in 1 blocks; 776 free (0 chunks); 7416 used
smgr relation table: 24576 total in 2 blocks; 8896 free (4 chunks); 15680 used
TransactionAbortContext: 32768 total in 1 blocks; 32728 free (0 chunks); 40 used
Portal hash: 8192 total in 1 blocks; 776 free (0 chunks); 7416 used
PortalMemory: 8192 total in 1 blocks; 7880 free (0 chunks); 312 used
PortalHeapMemory: 1024 total in 1 blocks; 792 free (0 chunks); 232 used
ExecutorState: 131280 total in 5 blocks; 53600 free (2 chunks); 77680 used
TupleSort main: 32824 total in 2 blocks; 7544 free (5 chunks); 25280 used
Caller tuples: 0 total in 0 blocks; 0 free (0 chunks); 0 used
printtup: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
Table function arguments: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
Relcache by OID: 24576 total in 2 blocks; 12960 free (4 chunks); 11616 used
CacheMemoryContext: 1040384 total in 7 blocks; 444944 free (0 chunks); 595440 used
pg_stat_activity: 23552 total in 5 blocks; 6464 free (0 chunks); 17088 used
…
pg_authid_rolname_index: 1024 total in 1 blocks; 400 free (0 chunks); 624 used
WAL record construction: 49768 total in 2 blocks; 6584 free (0 chunks); 43184 used
PrivateRefCount: 8192 total in 1 blocks; 2840 free (0 chunks); 5352 used
MdSmgr: 8192 total in 1 blocks; 7192 free (0 chunks); 1000 used
LOCALLOCK hash: 24576 total in 2 blocks; 13008 free (4 chunks); 11568 used
Timezones: 104120 total in 2 blocks; 2840 free (0 chunks); 101280 used
ErrorContext: 8192 total in 1 blocks; 8152 free (0 chunks); 40 used
Grand total: 2445712 bytes in 178 blocks; 886712 free (69 chunks); 1559000 used
<2018-05-25 14:46:00 CEST postgres postgres pgAdmin 4 - DB:postgres 127.0.0.1(62082) 0 > ERROR: out of memory
<2018-05-25 14:46:00 CEST postgres postgres pgAdmin 4 - DB:postgres 127.0.0.1(62082) 0 > DETAIL: Failed on request of size 167936.
<2018-05-25 14:46:00 CEST postgres postgres pgAdmin 4 - DB:postgres 127.0.0.1(62082) 0 > STATEMENT: /pga4dash/
SELECT
pid,
datname,
usename,
application_name,
client_addr,
to_char(backend_start, ‘YYYY-MM-DD HH24:MI:SS TZ’) AS backend_start,
state,
wait_event_type || ': ’ || wait_event AS wait_event,
pg_blocking_pids(pid) AS blocking_pids,
query,
to_char(state_change, ‘YYYY-MM-DD HH24:MI:SS TZ’) AS state_change,
to_char(query_start, ‘YYYY-MM-DD HH24:MI:SS TZ’) AS query_start
FROM
pg_stat_activity
ORDER BY pid
<2018-05-25 14:46:01 CEST 0 > LOG: CreateProcess call failed: unrecognized winsock error 10004 (error code 1455)
<2018-05-25 14:46:01 CEST 0 > LOG: could not fork autovacuum worker process: No error
Danach kommt nur noch die Warnung
<2018-05-25 14:47:01 CEST 0 > WARNING: worker took too long to start; canceled
Gibt es noch Hoffnung? Auf dem entsprechenden LW sind noch 8GB Speicher frei.
Viele Grüße Hedwig
begonnen hat das ganze mit
FATAL: password authentication failed for user “postgres”
DETAIL: Password does not match for user “postgres”.
Connection matched pg_hba.conf line 87: “host all all 111.20.333.0/23 md5”
An dem Passwort hat jedoch niemand etwas geändert, ich war ja auch schon angemeldet.
Eine Anmeldung mit trust statt md5 in der betreffenden Zeile brachte leider keinen Erfolg.
[/code]Nun - die erste Fehlermeldung ist eindeutig. Frage: nach der Änderung auf TRUST ein Reload/Restart gemacht?
Danach erscheint immer wieder die folgende Meldung, diese Tabelle existiert nicht, aber die Anwendung will offensichtlich darauf zugreifen.
ERROR: relation “meine_tabelle” does not exist at character 42
STATEMENT: Select place_of_statistic_reporting from meine_tabelle;Ist das zu 100% die reale Fehlermeldung, oder hast Du z.B. den Namen der Tabelle hier modifiziert?
Kann der x-fachen Versuch diesen Befehl auszuführen die Ursache sein? Denn nach ca. 4h kommt die Meldung
ERROR: relation “msysconf” does not exist at character 28
STATEMENT: SELECT Config, nValue FROM MSysConfWie heißt die Tabelle, ist diese evtl. mit GrOß uNd kLeInBuChStAbEn im Namen angelegt? PGAdmin macht sowas recht gerne…
unrecognized winsock error 10054
Dein Netzwerkstack scheint kapott zu sein. Ich vermute mal irgend welche Tischbrandschutzmauern oder Virenzeugs.
<2018-05-25 14:46:01 CEST 0 > LOG: CreateProcess call failed: unrecognized winsock error 10004 (error code 1455)
<2018-05-25 14:46:01 CEST 0 > LOG: could not fork autovacuum worker process: No errorDanach kommt nur noch die Warnung
<2018-05-25 14:47:01 CEST 0 > WARNING: worker took too long to start; canceledGibt es noch Hoffnung? Auf dem entsprechenden LW sind noch 8GB Speicher frei.
Hoffnung gibt es immer. Es ist aus Erfahrung eher schlecht, PostgreSQL auf einer Windows-Daddel-Kiste zu betreiben, auf dem dysfunktionaler Schrott wie Firewall, Virenscanner und ähnliche Schadsoftware läuft.
Um es mal so zu formulieren: wir haben weltweit einige hundert Kunden mit zehntausenden Servern. Selbst wenn ich mir an einer Hand alle Finger abhacken würde könnte ich noch immer alle Server da zählen, die mit Windows als OS laufen…
Welche PG-Version ist denn im Einsatz?
“msysconf” schein zur MS Jet database engine zu gehören, ODBC-Krams. Nutzt Du sowas? Mit der richtigen DB verbunden?
PS.: PostgreSQL bringt einen CLI mit (Command Line Interface), funktioniert dieser?
übrigens:
Connection matched pg_hba.conf line 87: “host all all 111.20.333.0/23 md5”
falsche / invalide CIDR-Adresse.
Sorry, dass ich mich erst jetzt melde, aber ich bin noch bis Mittwoch unterwegs und die letzte Veranstaltung ist gerade erst zu Ende.
Zuerst die gute Nachricht – der Zugriff funktioniert wieder!
Großes Dankeschön für die vielen Hinweise. Im Ergebnis habe ich heute Morgen den Server und den Postgresdienst noch mal neugestartet, dabei tauchte der Hinweis auf die hba.conf auf. Beim Überprüfen der hba.conf habe ich den Fehler gefunden. Erneuter Start des Postgresdienstes, noch mit TRUST führte zum Erfolg und auch mit md5 und Neustart des Dienstes kann wieder auf die Datenbank zugegriffen werden.
Als Nachtrag:
Die PG-Version ist 9.6 und diverse Programme greifen über ODBC auf die Datenbank zu – ist von den Entwicklern so vorgesehen. Die ODBC-Einstellungen sind alle in Ordnung und laufen so schon seit langer Zeit.
Den Tabellennamen hatte ich geändert, es werden nur Kleinbuchstaben und der _ verwendet, auch die IP-Adresse ist nur manipuliert - mein Chef ist sehr vorsichtig mit seinen Daten.
Um Windows, Firewall und Virenscanner komme ich nicht drum herum.
Leider konnte ich heute Morgen aus Zeitmangel nicht alles testen, das hole ich am Mittwochnachmittag nach und melde mich nochmal abschließend hier im Forum.
Na okay, wenn wieder alles geht.
Wenn das eine produktive DB ist würde ich dennoch empfehlen, von Windows wegzugehen und ein Linux, z.B. CentOS, zu nutzen.
Hallo, auch die Programme mit Datenbankanbindung tun wieder, was sie sollen!
Das Problem ist zum Glück “nur” auf dem Testsystem aufgetreten, aber auch das Produktivsystem läuft unter Windows mit Firewall. Wie schon erwähnt habe ich leider keinen Einfluss auf die Wahl des Betriebssystems, werde aber immer wieder darauf hinweisen.
Vielen Dank nochmal für Deine Hilfe.
you are welcome!