Обсуждение: Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executedquery.
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
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
Вложения
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
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