RE: [PG19] Promotion hangs behind a backend blocked on a stuck client

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