From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
Cc: | postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fsutil ideas |
Date: | 2006-02-24 18:33:58 |
Message-ID: | 1140806039.5092.155.camel@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2006-02-24 at 19:20 +0100, Csaba Nagy wrote:
> On Fri, 2006-02-24 at 19:12, Rod Taylor wrote:
> > On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
> > > Rod Taylor <pg(at)rbt(dot)ca> writes:
> > > > I watch for table bloat but I haven't figured out a nice way of tracking
> > > > down the postgresql process with the oldest transaction running short of
> > > > patching PostgreSQL to report the XID for a connection in
> > > > pg_stat_activity.
>
> But I'm afraid that a long running transaction with many short queries
> will not even show up in pg_stat_activity. So that's not a completely
> reliable way of catching long running transactions... but it's true that
> most of the time a long running query is the problem, and that is
> catchable.
The specific query may not show up but the process should appear in one
state or another.
That said, pg_locks would still show low XID (compared to the rest)
exists and that would probably be the culprit.
--
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-02-24 19:16:57 | Re: fsutil ideas |
Previous Message | Csaba Nagy | 2006-02-24 18:20:30 | Re: fsutil ideas |