Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

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

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


pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group