Re: Active connections are terminated because of small wal_sender_timeout
От | AYahorau@ibagroup.eu |
---|---|
Тема | Re: Active connections are terminated because of small wal_sender_timeout |
Дата | |
Msg-id | OF3E6F262D.A2F0D9BD-ON43258448.002D780D-43258448.002FDEA0@iba.by обсуждение исходный текст |
Ответ на | Re: Active connections are terminated because of smallwal_sender_timeout (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Active connections are terminated because of small wal_sender_timeout
|
Список | pgsql-general |
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
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
В списке pgsql-general по дате отправления: