vacuum'ing toast crumbs, detecting dangling transactions

Hi folks

I had a couple of semi-newbie questions about this, which I couldn't find obvious answers to in the archives ... we are using Postgres 8.3, and the behaviour is the same across Windows and Linux.

I am working with an app which, among other things stores XML files (average about 50KB in size) in blobs in Postgres (column type "text") which Postgres puts in a pg_toast_nnnnn table. The pattern of access is that a group of a few hundred new rows is written to the main table once every few hours, but then the XML documents in that recent batch of rows will be updated about once every 5 minutes each, until the next batch of new rows is created - in that way, the contents of the table are the most recent version of each document, plus a historical trail of one version every few hours.

I'm not defending the decision to store blobs in a database (it was taken a while ago, before the need for frequent updates of the XML) and it isn't something that can be readily changed at short notice, so please no advice about "don't do that" :-)

Obviously, the app causes high turnover of rows in both the parent table and the toast table, so it relies heavily on vacuum to keep the size down. There is no DBA here and no Postgres tuning has been done yet (I plan to have a poke, but my DB tuning experience is Oracle with a side of MySQL, I am a Postgres newbie).

Questions:

1. When I run vacuum manually on the parent table with the application running, it has no effect on either the parent or toast table (as reported by the "pgstattuple" add-on), even when the table is showing 40-50% dead tuples. However, if I disconnect the app, all the dead tuples clean up and moved to the "free space" category.

Is this a normal amount of dead space, and if not, what does this mean? My best guess is that (a) it's not normal, and (b) somewhere the app is holding open an old transaction, so Postgres thinks it has to retain all that data.

2. If there is a hanging transaction, what's the best way to trace it from the PG end? Client is classic Java (Spring / Hibernate / Apache DBCP) if that matters.

Cheers
Dave