Re: Autovacuum help..

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Sundar Narayanaswamy <sundar007(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Autovacuum help..
Date: 2006-08-02 15:36:28
Message-ID: 20060802153628.GJ29699@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Aug 02, 2006 at 07:36:09AM -0700, Sundar Narayanaswamy wrote:
> select * from ....;
> read rows from result set
> <Idle in transaction> (autovacuum cannot remove dead rows)
> <LONG time elapses>
> (autovacuum cannot remove dead rows)
> .
> .
> The last select operation is the one of concern. I was just raising the point
> that select by itself (like the one here) probably shouldn't put the
> connection in "Idle in transaction" mode.
>
> Since my app does not do a commit (or rollback) after every select (and
> selects in my app don't modify the database), the connection is left
> in "Idle in transaction" state for several hours until a next
> insert/update/delete followed by commit takes it to "idle" state.
> And, autovacuum is unable to remove the dead rows until connection goes
> to "idle" state.

Sorry, selects still advance the transaction counter, create a
snapshot, hold locks, can still fire triggers, update stats, call
external functions, etc. Maybe in your case they don't but maybe
someday you'll make a change to the database that will.

Maybe modify your app so selects arn't run inside an explicit
transaction. Then you don't need to commit or rollback anything.

> Perhaps, the solution is that I should modify my app to do a rollback
> followed by every select. But that is a little awkward because selects
> don't really modify the database in my case.

I imagine commit is cheaper and safer than a rollback...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2006-08-02 15:36:53 Re: Best Procedural Language?
Previous Message Wenjian Yang 2006-08-02 15:29:12 best ways to handle large matrix data