Skip site navigation (1) Skip section navigation (2)

another transaction ID question:

From: Kevin Kempter <kevin(at)kevinkempterllc(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: another transaction ID question:
Date: 2007-10-30 19:16:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Hi All;

In addition to bumping up the max_fsm_pages value, I'm preparing to run a full db vacuum to avoid a transaction ID wrap-around failure for an 8.1.4 server. (we do have autovacuum on, and we're using the 8.2 defaults). I'm doing this based on a recent message from a regular vacuum verbose of the postgres db:

CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  free space map contains 7464818 pages in 502 relations
DETAIL:  A total of 7500000 page slots are in use (including overhead).
19269120 page slots are required to track all free space.
Current limits are:  7500000 page slots, 1000 relations, using 44010 KB.
NOTICE:  number of page slots needed (19269120) exceeds max_fsm_pages (7500000)
HINT:  Consider increasing the configuration parameter "max_fsm_pages" to a value over 19269120.
WARNING:  database "emsam-1" must be vacuumed within 432563175 transactions
HINT:  To avoid a database shutdown, execute a full-database VACUUM in "emsam-1".

I'm looking at the pg_database table like so:
postgres=# select datname, age(datfrozenxid) from pg_database;
  datname  |    age
 postgres  | 1073744186
 emsam-1   | 1714922745
 template1 |  629788508
 template0 | 1961232297
(4 rows)

I see that template0 is closer than any other db to the 2Billion mark.
Of course if I try and connect to template0 I get this:

\c template0
FATAL:  database "template0" is not currently accepting connections
Previous connection kept

Do I need to vacuum template0 ?
If so, how to I alter perms so I can connect to it ?

Thanks in nadvance..



pgsql-admin by date

Next:From: Tom LaneDate: 2007-10-30 19:38:55
Subject: Re: another transaction ID question:
Previous:From: Chris BrowneDate: 2007-10-30 18:18:50
Subject: Re: Installing PostgreSQL as Admin

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group