Hello Everyone!
Sorry for being persistent.
> 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 and does 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 ?
Best regards,
Andrei Yahorau
