Finding the PID keeping a transaction open

From: Andrew Sullivan <andrew(at)libertyrms(dot)info>
To: pgsql-performance(at)postgresql(dot)org
Subject: Finding the PID keeping a transaction open
Date: 2003-03-25 13:12:34
Message-ID: 20030325081233.B18817@mail.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

Using 7.2.3 and 7.2.4 (the last .3 is being retired this weekend).

I'm struggling with an application which is keeping open a
transaction (or, likely from the results, more than one) against a
pair of frequently-updated tables. Unfortunately, the
frequently-updated tables are also a performance bottleneck.

These tables are small, but their physical size is very large,
because of all the updates.

The problem is, of course, that vacuum isn't working because
_something_ is holding open the transaction. But I can't tell what.

We connect to the database via JDBC; we have a pool which recycles
its connections. In the next version of the pool, the autocommit
foolishness (end transaction and issue immediate BEGIN) is gone, but
that won't help me in the case at hand.

What I'm trying to figure out is whether there is a way to learn
which pids are responsible for the long-running transaction(s) that
touch(es) the candidate tables. Then I can find a way of paring those
processes back, so that I can get vacuum to succeed.

I think there must be a way with gdb, but I'm stumped. Any
suggestions? The time a process has been living is not a guide,
because the connections (and hence processes) get recycled in the
pool.

A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-03-25 14:37:41 Re: Finding the PID keeping a transaction open
Previous Message Nikolaus Dilger 2003-03-25 03:26:57 Re: Slow query