Hello,

I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product has
a bug that causes it to leave connections persistent in a transaction
state. This is what it does:

BEGIN; SELECT 1;

Basically it is verifying that the connection is live. However, it never
calls commit. So what happens? We can't vacuum .

Anyway, my thought is, we know when a transaction is idle, why not have
an idle timeout where we will explicitly close the connection or
rollback or something? User configurable of course.

Sincerely,

Joshua D. Drake



--

=== 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 6: explain analyze is your friend

Joshua D. Drake wrote:
> Hello,
>
> I ran into an interesting problem with a customer today. They are
> running Jabber XCP (not the one we use). Unfortunately, the product
> has a bug that causes it to leave connections persistent in a
> transaction state. This is what it does:
>
> BEGIN; SELECT 1;
>
> Basically it is verifying that the connection is live. However, it
> never calls commit. So what happens? We can't vacuum .
>
> Anyway, my thought is, we know when a transaction is idle, why not
> have an idle timeout where we will explicitly close the connection or
> rollback or something? User configurable of course.
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.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Russell Smith wrote:
> Joshua D. Drake wrote:
>> Hello,
>>
>> I ran into an interesting problem with a customer today. They are
>> running Jabber XCP (not the one we use). Unfortunately, the product
>> has a bug that causes it to leave connections persistent in a
>> transaction state. This is what it does:
>>
>> BEGIN; SELECT 1;
>>
>> Basically it is verifying that the connection is live. However, it
>> never calls commit. So what happens? We can't vacuum .
>>
>> Anyway, my thought is, we know when a transaction is idle, why not
>> have an idle timeout where we will explicitly close the connection or
>> rollback or something? User configurable of course.
> 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.

Joshua D. Drake

>>
>> Sincerely,
>>
>> Joshua D. Drake
>>
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>


--

=== 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 2: Don't 'kill -9' the postmaster

"Joshua D. Drake" <jd@commandprompt.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

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

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

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.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?

Well of course that would be bad. That is why I said, idle in
transaction. If you are idle, you are doing nothing yes?

Joshua D. Drake


>
> 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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.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.

I should have read what you posted more thoroughly. I apologize. A
transaction timeout is surely a bad idea as Tom says below. Heck, not
just from what he says below, but what about the scenario that killing a
transaction could cause a massive rollback and thus increase the initial
problem that I posted about


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

Yeah, it could as high as something like 60 minutes if we really wanted.

Sincerely,

Joshua D. Drake

>
> 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 6: explain analyze is your friend

Added to TODO:

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


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

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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" <jd@commandprompt.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
>>
>> ---------------------------(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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Bruce Momjian wrote:
> Added to TODO:
>
> * Add idle_timeout GUC so locks are not held for log periods of time
>
>
>

ITYM long periods.


cheers


andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

fixed.


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

Joshua D. Drake wrote:
> 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" <jd@commandprompt.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
> >>
> >> ---------------------------(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/

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

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