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

Re: transaction ID query

From: Kevin Kempter <kevin(at)kevinkempterllc(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: transaction ID query
Date: 2007-09-03 18:54:51
Message-ID: 200709031254.52150.kevin@kevinkempterllc.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Thursday 30 August 2007 07:12:48 Alvaro Herrera wrote:
> Kevin Kempter wrote:
> > Hi List;
> >
> > can I run queries to see the following for postgres v 8.1.4:
>
> Update to 8.1.9 *soon* unless you want to be victim of a nasty autovac
> bug.  And in case you already were (which you won't know until your
> database starts causing you hard-to-fix headaches), I suggest you
> connect to template0 and run VACUUM FREEZE for precaution.
>
> > a) where the db is per used transaction ID's (want to avoid a transaction
> > ID wrap-around scenario)
>
> select age(datfrozenxid) from pg_database;
>
> > b) a list of tables in the db and the last time they were vacuumed
>
> Examine the pg_stat views, though I am not sure if the vacuum columns
> were already in 8.1.  In any case, in 8.1 Xid wraparound is tracked
> per-database, so you need database-wide vacuums.  In 8.2 it is per table
> so it is easier to keep up tokempt date.

I've run a vacuum verbose on the entire database (actually on all db's within 
the cluster) but now I still see large numbers for the following query. Am I 
missing something? Are these db's still in danger of a tx ID wrap-around 
failure?

ems-1=# select datname, age(datfrozenxid) from pg_database;
   datname   |    age
-------------+------------
 postgres    	| 1083972950
 rbc             	| 1083972554
 emsam-1-old | 1085384465
 template1   	| 1083966365
 template0   	| 1195263818
 ems-1       	| 1086979868


Thanks in advance...

/Kevin

In response to

Responses

pgsql-admin by date

Next:From: Tom LaneDate: 2007-09-03 19:21:50
Subject: Re: transaction ID query
Previous:From: Tom LaneDate: 2007-09-03 13:42:21
Subject: Re: FW: max_connections and shared_buffers

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