Re: BUG #16035: STATEMENT_TIMEOUT not working when we have single quote usage inside CTE which is used in inner sql
От | Tom Lane |
---|---|
Тема | Re: BUG #16035: STATEMENT_TIMEOUT not working when we have single quote usage inside CTE which is used in inner sql |
Дата | |
Msg-id | 14850.1571941169@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16035: STATEMENT_TIMEOUT not working when we have single quote usage inside CTE which is used in inner sql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I wrote: > Tatsuo Ishii <ishii@sraoss.co.jp> writes: >> With attached patch (against master), SET STATEMENT_TIMEOUT >> immediately affects to subsequent commands in the multi statement. I >> think this is not only more intuitive than v10's behavior but it meets >> the original reporter's expectation. > Hm. So, okay, that is a nicer API probably, but note that it also > has the effect that the timeout starts over again for each statement > in the string, while before it applied to the string as a whole. > Are we okay with that change? (I've not yet looked to see if it's > documented anywhere that it works that way...) It's kind of tossing > some of the optimization intended by f8e5f156b overboard, since when > a timeout is active we'll be doing timeout calculations for each > statement in the string. I looked around, and as far as I can tell, there is no detail at all about this in our user-facing docs. I think we should apply a doc patch more or less like the attached. This fails to provide a complete spec of what the behavior used to be, but I don't much care to try to document that 100% exactly. Anyone have an objection to pushing ahead with this for HEAD only? regards, tom lane diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 886632f..26ef8ff 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -7592,11 +7592,25 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; </term> <listitem> <para> - Abort any statement that takes more than the specified duration - (defaults to milliseconds), starting from the time the command arrives at the server - from the client. If <varname>log_min_error_statement</varname> is set to - <literal>ERROR</literal> or lower, the statement that timed out will also be - logged. A value of zero (the default) turns this off. + Abort any statement that takes more than the specified duration. + If <varname>log_min_error_statement</varname> is set + to <literal>ERROR</literal> or lower, the statement that timed out + will also be logged. + If the value is specified as a plain number, it is measured in + milliseconds by default. + A value of zero (the default) disables the timeout. + </para> + + <para> + The timeout is measured from the time a command arrives at the + server until it is completed by the server. If multiple SQL + statements appear in a single simple-Query message, the timeout + is applied to each statement separately. + (<productname>PostgreSQL</productname> versions before 13 usually + treated the timeout as applying to the whole query string.) + In extended query protocol, the timeout starts running when any + query-related message (Parse, Bind, Execute, Describe) arrives, and + it is cancelled by completion of an Execute or Sync message. </para> <para>
В списке pgsql-bugs по дате отправления: