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".
VACUUM



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
postgres=#  

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

Thanks in nadvance..

/Kevin

Reply via email to