Re: Idle In Transaction Session Timeout, revived - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Idle In Transaction Session Timeout, revived
Date
Msg-id CA+TgmoZ4P1cQetjOxQoHiG072UcE7dpE7dTBV8hMOidhwhof+g@mail.gmail.com
Whole thread Raw
In response to Re: Idle In Transaction Session Timeout, revived  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Fri, Mar 18, 2016 at 10:08 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Wed, Mar 16, 2016 at 8:32 AM, Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: GinPageIs* don't actually return a boolean
Next
From: Robert Haas
Date:
Subject: Re: Patch: fix lock contention for HASHHDR.mutex