Re: Transaction-Overflow

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