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!
>
great, important f
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
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 changing at
>> an inopportune time.
>
> Thanks for co
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 last year.
>>>
>>> This version does not s
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 feature.
I get a pretty str
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 where it would
>> jump ou
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. Consider this:
> >>
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=# lock table pg_class;
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=# sel
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 Andres' patch in commit
>
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
> > reason to suppose that it wi
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 har
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 see
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 where it would
>> jump o
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
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 Andres' patch in commit
>
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 dropping the connection, they can write a patch to
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 provide
>>> that as an additional option. T
"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 before.
>> But the fact th
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 resources keeping the connection o
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 roll the transaction back and not
> disconnect?
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.
>
>
> Except you end up losing s
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 how messy this would be in practice. But if we thi
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 practice. But if we think that
> killing the whole
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 handle it without losing sync. Basically, if you send
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 from last year.
>>>
>>> This version does not su
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
jump out of SSL code than
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 Andres' patch in commit
>
28 matches
Mail list logo
