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

From Andres Freund
Subject Re: Idle In Transaction Session Timeout, revived
Date
Msg-id 20160308230819.6kx4ihcjyq6u3es5@alap3.anarazel.de
Whole thread Raw
In response to Re: Idle In Transaction Session Timeout, revived  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Idle In Transaction Session Timeout, revived
List pgsql-hackers
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=# select 1/0;
> ERROR:  division by zero

Probably only if the toplevel transaction is also aborted. Might not be
entirely trivial to determine.

> - What's the right order of events in PostgresMain?  Right now the
> patch disables the timeout after checking for interrupts and clearing
> DoingCommandRead, but maybe it would be better to disable the timeout
> first, so that we can't have it happen that start to execute the
> command and then, in medias res, bomb out because of the idle timeout.
> Then again, maybe you had some compelling reason for doing it this
> way, in which case we should document that in the comments.

Hm, we should never bomb out of the middle of anything with this, right?
I mean all the itmeout handler does is set a volatile var and set a
latch, the rest is done in the interrupt handler? Which is not called in
the signal handler.

I'm no targuing for the current order, just that one argument ;). FWIW,
I think Vik wrote this after discussing with me, and IIRC there was not
a lot of reasoning going into the specific location for doing this.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Add generate_series(date,date) and generate_series(date,date,integer)
Next
From: Tom Lane
Date:
Subject: Re: PATCH: index-only scans with partial indexes