Re: Statement timeout - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Statement timeout
Date
Msg-id 7069.1464711558@sss.pgh.pa.us
Whole thread Raw
In response to Re: Statement timeout  (Tatsuo Ishii <ishii@postgresql.org>)
Responses Re: Statement timeout  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
Tatsuo Ishii <ishii@postgresql.org> writes:
>> Oops. Previous example was not appropriate. Here are revised
>> examples. (in any case, the time consumed at parse and bind are small,
>> and I omit the CHECK_FOR_INTERRUPTS after these commands)

FWIW, I think the existing behavior is just fine.  It corresponds to what
PQexec has always done with multi-statement query strings; that is,
statement_timeout governs the total time to execute the transaction (the
whole query string, unless you put transaction control commands in there).
In extended query mode, since you can only put one textual query per Parse
message, that maps to statement_timeout governing the total time from
initial Parse to Sync.  Which is what it does.

What you propose here is not a bug fix but a redefinition of what
statement_timeout does; and you've made it inconsistent with simple query
mode.  I don't really think it's an improvement.

BTW, aren't you missing a re-enable of the timeout for statements after
the first one?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Kevin Grittner
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <