Horton

Thread

Commits

  1. Clear stmt_timeout_active if we disable_all_timeouts.

  2. Rearm statement_timeout after each executed query.

  1. pgsql: Rearm statement_timeout after each executed query.

    Andres Freund <andres@anarazel.de> — 2017-09-19T02:41:00Z

    Rearm statement_timeout after each executed query.

Previously statement_timeout, in the extended protocol, affected all
messages till a Sync message.  For clients that pipeline/batch query
execution that's problematic.

Instead disable timeout after each Execute message, and enable, if
necessary, the timer in start_xact_command(). As that's done only for
Execute and not Parse / Bind, pipelining the latter two could still
cause undesirable timeouts. But a survey of protocol implementations
shows that all drivers issue Sync messages when preparing, and adding
timeout rearming to both is fairly expensive for the common parse /
bind / execute sequence.

Author: Tatsuo Ishii, editorialized by Andres Freund
Reviewed-By: Takayuki Tsunakawa, Andres Freund
Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@sraoss.co.jp

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/f8e5f156b30efee5d0038b03e38735773abcb7ed

Modified Files
--------------
src/backend/tcop/postgres.c | 77 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 65 insertions(+), 12 deletions(-)

  2. Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2018-02-06T04:21:44Z

    On 9/18/17 22:41, Andres Freund wrote:
> Rearm statement_timeout after each executed query.

This appears to have broken statement_timeout behavior in master such
that only every second query is affected by it.  For example:

create table t1 as select * from generate_series(0, 100000000) as _(a);
set statement_timeout = '1s';
explain analyze select from t1 where a = 55;  -- gets canceled
explain analyze select from t1 where a = 55;  -- completes (>1s)
explain analyze select from t1 where a = 55;  -- gets canceled
explain analyze select from t1 where a = 55;  -- completes (>1s)
etc.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  3. Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

    Thomas Munro <thomas.munro@enterprisedb.com> — 2018-02-08T00:04:13Z

    On Tue, Feb 6, 2018 at 5:21 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 9/18/17 22:41, Andres Freund wrote:
>> Rearm statement_timeout after each executed query.
>
> This appears to have broken statement_timeout behavior in master such
> that only every second query is affected by it.

Yeah, I also just ran into this while testing a nearby complaint about
statement timeouts vs parallel query.  In the error path
stmt_timeout_active remains true, so the next statement does nothing
in enable_statement_timeout().  I think we just need to clear that
flag in the error path, right where we call disable_all_timeouts().
See attached.

-- 
Thomas Munro
http://www.enterprisedb.com

  4. Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

    Robert Haas <robertmhaas@gmail.com> — 2018-02-09T20:50:44Z

    On Wed, Feb 7, 2018 at 7:04 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Feb 6, 2018 at 5:21 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> On 9/18/17 22:41, Andres Freund wrote:
>>> Rearm statement_timeout after each executed query.
>>
>> This appears to have broken statement_timeout behavior in master such
>> that only every second query is affected by it.
>
> Yeah, I also just ran into this while testing a nearby complaint about
> statement timeouts vs parallel query.  In the error path
> stmt_timeout_active remains true, so the next statement does nothing
> in enable_statement_timeout().  I think we just need to clear that
> flag in the error path, right where we call disable_all_timeouts().
> See attached.

Looks right.  Committed, but I thought the comment was strange (forget
about?) so I just left that out.

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

  5. Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

    Andres Freund <andres@anarazel.de> — 2018-02-14T18:35:08Z

    On 2018-02-09 15:50:44 -0500, Robert Haas wrote:
> On Wed, Feb 7, 2018 at 7:04 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > On Tue, Feb 6, 2018 at 5:21 PM, Peter Eisentraut
> > <peter.eisentraut@2ndquadrant.com> wrote:
> >> On 9/18/17 22:41, Andres Freund wrote:
> >>> Rearm statement_timeout after each executed query.
> >>
> >> This appears to have broken statement_timeout behavior in master such
> >> that only every second query is affected by it.
> >
> > Yeah, I also just ran into this while testing a nearby complaint about
> > statement timeouts vs parallel query.  In the error path
> > stmt_timeout_active remains true, so the next statement does nothing
> > in enable_statement_timeout().  I think we just need to clear that
> > flag in the error path, right where we call disable_all_timeouts().
> > See attached.
> 
> Looks right.  Committed, but I thought the comment was strange (forget
> about?) so I just left that out.

Thanks Peter, Thomas, Robert!

- Andres