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

Re: Connection Idle in transaction

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: David Wall <d(dot)wall(at)computer(dot)org>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Connection Idle in transaction
Date: 2004-04-09 03:11:09
Message-ID: 4076144D.2030003@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
David Wall wrote:
>>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?

Empirically, an open transaction that has run no queries *does* prevent 
some rows from being vacuumed. I haven't delved into the backend code to 
see why exactly; asking on -hackers may be a better bet.

> 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.

That's the plan; it just needs implementing. There are also some 
interactions with changing transaction isolation levels that should be 
dealt with at the same time.

This is somewhere on my todo list and I'll get to it eventually if noone 
else does, but there's quite a bit of other stuff ahead of it at the 
moment..

-O

In response to

Responses

pgsql-jdbc by date

Next:From: David WallDate: 2004-04-09 03:23:59
Subject: Re: Connection Idle in transaction
Previous:From: David WallDate: 2004-04-09 02:35:40
Subject: Re: Connection Idle in transaction

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