Обсуждение: Close open transactions soon to avoid wraparound problems

Vacuumdb is giving me these messages:

Vacuuming public.files...
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.
VACUUM

Two questions:
1. Is there a way for me to see what application/host/user has open transactions that need to be closed?
2. If #1 is not possible then what can I do about this?

Searching the web via normal methods only turns up indexed source code files for vacuum.

What's been done so far:
-Cluster-wide vacuum (these are done nightly, I ran one again just for gp)
-Ran the following query looking for old/suspicious connections/transactions, didn't find anything useful:

select procpid, datname, client_addr, usename, current_query, query_start from pg_stat_activity order by query_start asc;

Thanks in advance,
Brian

Brian Staszewski <brian.staszewski@farheap.com> writes:
> WARNING:  oldest xmin is far in the past
> HINT:  Close open transactions soon to avoid wraparound problems.

Hmm ... which PG version is this?  I think 8.2 will start to complain
about this much earlier than older versions (~ 100M transactions by
default, instead of 1000M).  Though you've probably got a problem
here in any case.

> What's been done so far:
> -Cluster-wide vacuum (these are done nightly, I ran one again just for gp)

Not relevant

> -Ran the following query looking for old/suspicious
> connections/transactions, didn't find anything useful:
> select procpid, datname, client_addr, usename, current_query,
> query_start from pg_stat_activity order by query_start asc;

Most likely the problem transaction is sitting idle and hence has null
query_start.  Try "ps auxww" or local equivalent and look for postgres
processes that are very old and are in "idle in transaction" state.

            regards, tom lane

Tom Lane wrote:

Brian Staszewski <brian.staszewski@farheap.com> writes: 

WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.   

Hmm ... which PG version is this?  I think 8.2 will start to complain
about this much earlier than older versions (~ 100M transactions by
default, instead of 1000M).  Though you've probably got a problem
here in any case.
 

Yep, 8.2.4.

What's been done so far:
-Cluster-wide vacuum (these are done nightly, I ran one again just for gp)   

Not relevant
 

-Ran the following query looking for old/suspicious 
connections/transactions, didn't find anything useful:
select procpid, datname, client_addr, usename, current_query, 
query_start from pg_stat_activity order by query_start asc;   

Most likely the problem transaction is sitting idle and hence has null
query_start.  Try "ps auxww" or local equivalent and look for postgres
processes that are very old and are in "idle in transaction" state.
		regards, tom lane 

"ps auxww | grep trans " did in fact reveal three processes that were 2, 3, and 4 days old that the query above didn't show. The connections were from three different application servers and restarting the pools on those servers corrected the problem.

Thanks,
Brian