Re: Idle In Transaction Session Timeout, revived

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Vik Fearing <vik(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Idle In Transaction Session Timeout, revived
Date: 2016-03-19 13:29:14
Message-ID: CA+TgmoZ4P1cQetjOxQoHiG072UcE7dpE7dTBV8hMOidhwhof+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 18, 2016 at 10:08 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Wed, Mar 16, 2016 at 8:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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 strange error message:
>
> jjanes=# set idle_in_transaction_session_timeout = "1s";
> jjanes=# begin;
> -- wait for more than 1 second.
> jjanes=# select count(*) from pgbench_accounts;
> FATAL: terminating connection due to idle-in-transaction timeout
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Succeeded.
>
>
> First it tells me exactly why the connection was killed, then it tells
> me it doesn't know why the connection was killed and probably the
> server has crashed.
>
> I can't find the spot in the code where the FATAL message is getting
> printed. I suppose it will not be easy to pass a
> "dont_plead_ignorance" flag over to the part that prints the follow-up
> message?

The "This probably means the server terminated abnormally" message is
coming from libpq, while the FATAL error is coming from the server.
One might think that libpq should be prepared for the connection to be
closed if the server has sent a FATAL error, but I think the fact that
it isn't is a general problem, not related to this particular patch.
It would be good to think about how we might fix that...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-19 13:32:22 Re: Patch: fix lock contention for HASHHDR.mutex
Previous Message Michael Paquier 2016-03-19 12:43:25 Re: GinPageIs* don't actually return a boolean