Dear Amit,
> Will this help when the promotion is stuck? I feel this defeats the
> purpose of the feature introduced in commit 67c20979ce7. Also, not
> sure saying: " 15 minutes with default TCP settings" doesn't sound
> like a good idea because default on Windows may be different;
> additionally, if the client is alive but has stopped reading, it can
> take much more time. I have tried to make it generic in the attached
> (the patch is atop v20 for now).
Yes, the original patch was too Linux-specific, in general yours was better.
Few comments:
```
+ On a standby with <varname>wal_level</varname> set to
+ <literal>replica</literal> that has a logical replication slot
```
We can clarify that the valid replication slot is needed.
```
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.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
