Bruce Momjian wrote:
Added to TODO:

        * Add idle_timeout GUC so locks are not held for log periods of time


That should actually be transaction_idle_timeout. It is o.k. for us to be IDLE... it is not o.k. for us to be IDLE in Transaction


Joshua D. Drake




---------------------------------------------------------------------------

Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

                http://www.postgresql.org/about/donate



--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to