Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-19 Thread Pavel Stehule
2016-03-16 17:54 GMT+01:00 Vik Fearing : > On 03/16/2016 05:32 PM, Robert Haas wrote: > > > Committed with slight changes to the docs, and I added a flag variable > > instead of relying on IdleInTransactionSessionTimeout not changing at > > an inopportune time. > > Thank you!

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-19 Thread Vik Fearing
On 03/16/2016 05:32 PM, Robert Haas wrote: > Committed with slight changes to the docs, and I added a flag variable > instead of relying on IdleInTransactionSessionTimeout not changing at > an inopportune time. Thank you! -- Vik Fearing +33 6 46 75 15 36

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-19 Thread Robert Haas
On Fri, Mar 18, 2016 at 10:08 PM, Jeff Janes wrote: > On Wed, Mar 16, 2016 at 8:32 AM, Robert Haas wrote: >> >> Committed with slight changes to the docs, and I added a flag variable >> instead of relying on IdleInTransactionSessionTimeout not

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-19 Thread Robert Haas
On Tue, Mar 15, 2016 at 8:08 PM, Vik Fearing wrote: > On 03/08/2016 10:42 PM, Robert Haas wrote: >> On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: >>> Attached is a rebased and revised version of my >>> idle_in_transaction_session_timeout patch from

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-18 Thread Jeff Janes
On Wed, Mar 16, 2016 at 8:32 AM, Robert Haas wrote: > > Committed with slight changes to the docs, and I added a flag variable > instead of relying on IdleInTransactionSessionTimeout not changing at > an inopportune time. Thanks for committing, this should be a useful

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-15 Thread Vik Fearing
On 03/08/2016 10:42 PM, Robert Haas wrote: > On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: >> Attached is a rebased and revised version of my >> idle_in_transaction_session_timeout patch from last year. >> >> This version does not suffer the problems the old one did

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-15 Thread Andres Freund
On 2016-03-15 14:21:34 -0400, Robert Haas wrote: > On Tue, Mar 8, 2016 at 6:08 PM, Andres Freund wrote: > > On 2016-03-08 16:42:37 -0500, Robert Haas wrote: > >> - I really wonder if the decision to ignore sessions that are idle in > >> transaction (aborted) should revisited.

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-15 Thread Robert Haas
On Tue, Mar 8, 2016 at 6:08 PM, Andres Freund wrote: > On 2016-03-08 16:42:37 -0500, Robert Haas wrote: >> - I really wonder if the decision to ignore sessions that are idle in >> transaction (aborted) should revisited. Consider this: >> >> rhaas=# begin; >> BEGIN >> rhaas=#

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-08 Thread Andres Freund
On 2016-03-08 16:42:37 -0500, Robert Haas wrote: > - I really wonder if the decision to ignore sessions that are idle in > transaction (aborted) should revisited. Consider this: > > rhaas=# begin; > BEGIN > rhaas=# lock table pg_class; > LOCK TABLE > rhaas=# savepoint a; > SAVEPOINT > rhaas=#

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-03-08 Thread Robert Haas
On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: > Attached is a rebased and revised version of my > idle_in_transaction_session_timeout patch from last year. > > This version does not suffer the problems the old one did where it would > jump out of SSL code thanks to

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-07 Thread Craig Ringer
On 4 February 2016 at 09:04, Robert Haas wrote: > > I have the same uneasy feeling about it as JD. However, you could > > certainly argue that if the client application has lost its marbles > > to the extent of allowing a transaction to time out, there's no good > >

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-04 Thread Fujii Masao
On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing wrote: > Attached is a rebased and revised version of my > idle_in_transaction_session_timeout patch from last year. > > This version does not suffer the problems the old one did where it would > jump out of SSL code thanks to

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-04 Thread Alvaro Herrera
David Steele wrote: > > <...> But what I think really happens is > > some badly-written Java application loses track of a connection > > someplace and just never finds it again. <...> I've seen that also, plenty of times. > That's what I've seen over and over again. And then sometimes it's not

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-04 Thread David Steele
On 2/4/16 5:00 AM, Alvaro Herrera wrote: > David Steele wrote: > >>> <...> But what I think really happens is >>> some badly-written Java application loses track of a connection >>> someplace and just never finds it again. <...> > > I've seen that also, plenty of times. > >> That's what I've

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-04 Thread Vik Fearing
On 02/04/2016 02:24 PM, Fujii Masao wrote: > On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing wrote: >> Attached is a rebased and revised version of my >> idle_in_transaction_session_timeout patch from last year. >> >> This version does not suffer the problems the old one did

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-04 Thread Andres Freund
On 2016-02-04 22:24:50 +0900, Fujii Masao wrote: > But, IIRC, one of the problems that prevent the adoption of this feature is > the addition of gettimeofday() call after every SQL command receipt. > Have you already resolved that problem? Or we don't need to care about > it because it's almost

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Robert Haas
On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: > Attached is a rebased and revised version of my > idle_in_transaction_session_timeout patch from last year. > > This version does not suffer the problems the old one did where it would > jump out of SSL code thanks to

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Jim Nasby
On 2/3/16 2:30 PM, Robert Haas wrote: On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: Attached is a rebased and revised version of my idle_in_transaction_session_timeout patch from last year. This version does not suffer the problems the old one did where it would

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Tom Lane
Robert Haas writes: > On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby wrote: >> Wouldn't it be more sensible to just roll the transaction back and not >> disconnect? > It would be nice to be able to do that, but the client-server protocol > can't

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread David Steele
On 2/3/16 4:25 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby wrote: >>> Wouldn't it be more sensible to just roll the transaction back and not >>> disconnect? > > I'm not sure how messy this would be in

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Robert Haas
On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby wrote: > On 2/3/16 2:30 PM, Robert Haas wrote: >> >> On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: >>> >>> Attached is a rebased and revised version of my >>> idle_in_transaction_session_timeout patch

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Robert Haas
On Wed, Feb 3, 2016 at 5:36 PM, Jim Nasby wrote: >> I think killing the session is a perfectly sensible thing to do in this >> case. Everything meaningful that was done in the session will be rolled >> back - no need to waste resources keeping the connection open. > > >

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Jim Nasby
On 2/3/16 4:05 PM, David Steele wrote: On 2/3/16 4:25 PM, Tom Lane wrote: Robert Haas writes: On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby wrote: Wouldn't it be more sensible to just roll the transaction back and not disconnect? I'm not sure

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Tom Lane
"Joshua D. Drake" writes: > On 02/03/2016 02:52 PM, Robert Haas wrote: >> Well, my view is that if somebody wants an alternative behavior >> besides dropping the connection, they can write a patch to provide >> that as an additional option. That, too, has been discussed

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Vik Fearing
On 02/03/2016 11:36 PM, Jim Nasby wrote: > On 2/3/16 4:05 PM, David Steele wrote: >> On 2/3/16 4:25 PM, Tom Lane wrote: >>> Robert Haas writes: On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby wrote: > Wouldn't it be more sensible to just

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Robert Haas
On Wed, Feb 3, 2016 at 6:16 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On 02/03/2016 02:52 PM, Robert Haas wrote: >>> Well, my view is that if somebody wants an alternative behavior >>> besides dropping the connection, they can write a patch to

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread David Steele
On 2/3/16 8:04 PM, Robert Haas wrote: > On Wed, Feb 3, 2016 at 6:16 PM, Tom Lane wrote: >> "Joshua D. Drake" writes: >>> On 02/03/2016 02:52 PM, Robert Haas wrote: Well, my view is that if somebody wants an alternative behavior besides

Re: [HACKERS] Idle In Transaction Session Timeout, revived

2016-02-03 Thread Joshua D. Drake
On 02/03/2016 02:52 PM, Robert Haas wrote: On Wed, Feb 3, 2016 at 5:36 PM, Jim Nasby wrote: I think killing the session is a perfectly sensible thing to do in this case. Everything meaningful that was done in the session will be rolled back - no need to waste

[HACKERS] Idle In Transaction Session Timeout, revived

2016-01-31 Thread Vik Fearing
Attached is a rebased and revised version of my idle_in_transaction_session_timeout patch from last year. This version does not suffer the problems the old one did where it would jump out of SSL code thanks to Andres' patch in commit 4f85fde8eb860f263384fffdca660e16e77c7f76. The basic idea is if