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 02:03:36
Message-ID: 40760478.5020603@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

David Wall wrote:
>>Not block sorry, but the vacuum is not able to free all the row updated
>>by other connections.
>
>
> But each connection shouldn't have any updated rows that haven't been
> committed or rolled back. Now, if you are running some statements against a
> connection and then never calling commit/rollback, that's another thing
> since you are actually tying up resources then. But since the driver just
> does a 'begin' after any given commit/rollback, there shouldn't be anything
> locked by that connection.

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.

For example:

> test=> select * from t;
> i | j
> ---+---
> 1 | 1
> 2 | 2
> 3 | 3
> (3 rows)
>
> test=> vacuum full verbose t;
> INFO: vacuuming "public.t"
> INFO: "t": found 3 removable, 3 nonremovable row versions in 1 pages
> DETAIL: 0 dead row versions cannot be removed yet. [...]

> test=> begin;
> BEGIN

On a separate connection:

> test=> update t set j=5 where i=3;
> UPDATE 1
> test=> vacuum full verbose t;
> INFO: vacuuming "public.t"
> INFO: "t": found 0 removable, 4 nonremovable row versions in 1 pages
> DETAIL: 1 dead row versions cannot be removed yet. [...]

Back on the original connection:

> test=> commit;
> COMMIT
> test=> vacuum full verbose t;
> INFO: vacuuming "public.t"
> INFO: "t": found 1 removable, 3 nonremovable row versions in 1 pages
> DETAIL: 0 dead row versions cannot be removed yet. [...]

So the open transaction prevents the old version of the row (where i=3
and j=3) from being removed.

I have a feeling this is an implementation artifact more than anything
-- as it appears that the snapshot to use for a (serializable)
transaction is not actually "taken" until the first query in a
transaction is executed, so the unremovable row in the above example is
never actually needed. But I'm not familiar with how the backend code
works so this is mostly guesswork :)

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message David Wall 2004-04-09 02:35:40 Re: Connection Idle in transaction
Previous Message Warren Little 2004-04-09 01:59:23 Re: Connection Idle in transaction