> It's not a lock issue as I understand it. It's that the presence of an
> open "old" transaction means that for rows that have been updated since
> that transaction started, VACUUM cannot delete the "old" version of the
row.
Why would the "old" transaction have anything locked up if it hadn't done a
select, update, insert or delete? And if it did, then why not
commit/rollback and leave the connection in a more clean state? Two
transactions shouldn't bother one another.
I'm not sure what state information is maintained in the JDBC library, but
assuming it can maintain state, it shouldn't be hard for it to know whether
it's in autocommit mode or not, and if not, then only issue the 'begin' when
a statement is first created on the connection, and then reset that state
after a commit/rollback.
But I'm going to look at my dbs with the vacuum full verbose command and see
if there's anything stuck in my system!
David
