Re: Feature thought: idle in transaction timeout

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Russell Smith <mr-russ(at)pws(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature thought: idle in transaction timeout
Date: 2007-03-31 16:03:10
Message-ID: 6206.1175356990@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Russell Smith wrote:
>> I agree with this, it reduces the long running transaction problem a
>> little where the user forgot to commit/rollback their session. I may be
>> worth having a transaction_timeout as well, and setting it to link a few
>> hours by default. That way you can't have really long running
>> transactions unless you specifically set that.

> We would certainly need to be able to disable on the fly too just with
> SET as well.

AFAICS, a *transaction* timeout per se has no use whatever except as a
foot-gun. How will you feel when you start a 12-hour restore, go home
for the evening, and come back in the morning to find it aborted because
you forgot to disable your 4-hour timeout?

Furthermore, if you have to set transaction_timeout to multiple hours
in the (vain) hope of not killing something important, what use is it
really? If you want to keep VACUUM able to work in a busy database,
you need it to be a lot less than that.

An *idle* timeout seems less risky, as well as much easier to pick a
sane value for.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-31 16:10:54 Re: Feature thought: idle in transaction timeout
Previous Message Tom Lane 2007-03-31 15:46:06 Re: Last minute mini-proposal (I know, I know) forPQexecf()