From: Tom Lane <tgl@sss.pgh.pa.us>
To: teng_wang13@163.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17537: Dynamically updating statement_timeout not affect the
 insert query right now.
In-reply-to: <17537-9c5b29383602bca0@postgresql.org>
References: <17537-9c5b29383602bca0@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 03 Jul 2022 05:24:10 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1216662.1656860480.1@sss.pgh.pa.us>
Date: Sun, 03 Jul 2022 11:01:20 -0400
Message-ID: <1216663.1656860480@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1216663.1656860480%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> However, dynamically updating statement_timeout did not affect the insert
> query right now.
> I start up Postgres with statement_timeout set 0, which means disabling the
> timeout. Then I insert 100000000 rows into a table, which finally takes
> 166498.487ms. During the insert operation, I consider the operation would
> takes too much time. So I update statement_timeout to 10s in
> postgresql.conf, and "select pg_reload_conf();" in another session to reload
> configuration files.

This is not a bug.  Active sessions absorb new values from postgresql.conf
only when idle, not instantaneously mid-query (and I'm pretty sure that is
documented, though I'm too lazy to search the docs right now).  I think
trying to do the latter would break far more scenarios than it would
improve.

			regards, tom lane