| 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: | Whole Thread | Raw Message | 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 |