|
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 |
