On Wed, Oct 21, 2026 at 2:36 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > ``` > The setting takes effect only for connections > + established after it is configured, > ``` > > Hmm, is it correct? > There is an assign hook which can update the socket option. My below > experiment > also indicated that TCP_USER_TIMEOUT can be enabled for established > connections. > > 1. Connected via TCP connection > $ psql -h 127.0.0.1 -U postgres > > 2. Set the tcp_user_timeout > > ``` > postgres=# SHOW tcp_user_timeout ; > tcp_user_timeout > ------------------ > 0 > (1 row) > > postgres=# SET tcp_user_timeout = '3s'; > SET > ``` > > 3. Sent a large amount of data to the client. > > ``` > postgres=# COPY ( > SELECT repeat('x', 1000000) > FROM generate_series(1, 100000) > ) TO STDOUT; > ``` > > 4. Sent a STOP signal to psql process, from another terminal > ``` > $ kill -STOP 40049 > ``` > > 5. After sometime the backend could be terminated due to the tcp timeout. > According to the log: > > ``` > LOG: could not send data to client: Connection timed out > STATEMENT: COPY ( > SELECT repeat('x', 1000000) > FROM generate_series(1, 100000) > ) TO STDOUT; > ``` > > Note: the backend could retain if step2 was skipped. >
Thanks for the test but how can the user know when to set it, if not before connection? Anyway, how about something generic as follows: - To bound such waits in advance, set - <varname>tcp_user_timeout</varname> on the standby, where supported by - the operating system. The setting takes effect only for connections - established after it is configured, and does not affect a connection - whose backend is already blocked. + To bound such waits, configure <varname>tcp_user_timeout</varname> on + the standby ahead of time, for example in + <filename>postgresql.conf</filename>, where supported by the operating + system. Setting it after a backend is already blocked sending data has + no effect on that backend. -- With Regards, Amit Kapila.
