On Mon, 2 May 2005 03:05 pm, Neil Conway wrote:
> Tom Lane wrote:
> > We would? Why? Please provide a motivation that justifies the
> > considerably higher cost to make it count that way, as opposed to
> > time-since-BEGIN.
>
> The specific scenario this feature is intended to resolve is
> idle-in-transaction backends holding on to resources while the network
> connection times out; it isn't intended to implement "I never want to
> run a transaction that takes more than X seconds to execute." While
> long-running transactions aren't usually a great idea, I can certainly
> imagine installations in which some transactions might take, say, 30
> minutes to execute but the admin would like to timeout idle connections
> in less than that amount of time.
>
The two big long running transactions I can think of are VACUUM on a large db,
and there is no way to shorten that time, since to stop wraparound you must
vacuum
the whole db.
Backups with pg_dump can run for quite a long time.
I would prefer an idle timeout if it's not costly. Because otherwise estimates
need to be
made about how long VACUUM and backup could take, and set the timeout longer.
Which
in some senses defeats the purpose of being able to cleanup idle connection
quickly.
The VACUUM issue may not be a problem, as if BEGIN is not issued, then the
transaction
timeout would probably not be used. But the issues would remain for backups.
Just some thoughts
Regards
Russell Smith
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
