Обсуждение: 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

Kevin Kempter <kevin@kevinkempterllc.com> writes:
> Do I need to vacuum template0 ?

No.

            regards, tom lane