> I do not think anybody thinks this is a bug. Setting wal_sender_timeout > too small is a configuration mistake.
Why is it a configuration mistake? This value is allowed to be set. There is no any restriction about it. I would like to ask a question regarding wal_sender_timeout description and its real behaviour. Description: Terminate replication connections that are inactive longer than the specified number of milliseconds. Real behaviour: A standby server can be busy anddoes not send "keepalive" packets to the master. (By the way wal_sender_timeot cannot be not so small as in my tests. This situation can happen when wal_sender_timeout=10seconds and so on and and so forth).
Does it work properly according to the description? Don't you see the contradiction between the description and real behaviour? As I mentioned before the connection between master and standby is good. There is no any problem. So where is a bug: in the description or in the implementation?
> Yeah. I don't see any bug here. Please note that it can be also a > problem to set up a too high value in some configuration setups. The > lack of flexibility in this area is why wal_sender_timeout has been > switch to be user-settable in v12. In short you can configure it in > the connection string to enforce a custom value per standby.
Will a small value of wal_sender_timeout in PostgreSQL v12 lead to the same failure "terminating walsender process due to replication timeout" as we observe in v11 ?
