Hi Tom, thank you for the very fast answer! On the top in the log file is this, do you know why the pid is killed with 11? I'm a little bit confused :(. LOG: Serverprozess (PID 30399) wurde von Signal 11 beendet LOG: aktive Serverprozesse werden abgebrochen WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht h at. TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können. WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses DETAIL: Der Postmaster hat diesen Serverprozess angewiesen, die aktuelle Transaktion zurückzurollen und die Sitzung zu beenden, weil ein anderer Serverprozess abnormal beendet wurde und möglicherweise das Shared Memory verfälscht h at. The log says also that the max possible xid is 1187023047: LOG: Grenze für Transaktionsnummernüberlauf ist 1187023047, begrenzt durch Datenbank »mydb« And my DB is already on 1076856894: isohost=# SELECT datname, age(datfrozenxid) FROM pg_database; datname | age -----------+------------ postgres | 116395795 template1 | 116395795 template0 | 116395795 mydb | 1076856894 Should this be the problem? What if the max xid is reached, does postgres then do a restart? How can I clean the counter, this should "vacuum analyze" do, or? Is it possible, that vacuum (without full) doesn't freeing any space, if max_fsm_pages are set to low? I've read something like this in the admin-mailinglist. Thanks a lot! Regards, Martin _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
