another transaction ID question:

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