Thread: 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
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
Attachment
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:
Thanks,
Brian
Yep, 8.2.4.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.
"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.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
Thanks,
Brian