Re: Active connections are terminated because of small wal_sender_timeout

From: AYahorau(at)ibagroup(dot)eu
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-general(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Active connections are terminated because of small wal_sender_timeout
Date: 2019-07-09 08:12:40
Message-ID: OFDB839DBE.5A49EC5C-ON43258432.002BADDE-43258432.002D1AFB@iba.by
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello Everyone!

> I do not think anybody thinks this is a bug. Setting
wal_sender_timeout
> too small is a configuration mistake.
I don't understand why it is a mistake. 1second is acceptable value for
wal_sender_timeout.
Moreover the behaviour contradicts with the official description for
wal_sender_timeout:
Terminate replication connections that are inactive longer than the
specified number of milliseconds.

First of all the connection between the master and standby was good in
my example. The problem was in keepalive message processing (because of
busy standby server).
So, here 2 variants are possible:
1). Inappropriate keepalive message processing which contradicts with
wal_sender_timeout description.
2) Incorrect description of wal_sender_timeout parameter in the
documentation.

> 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.
Thanks for this announcement, This enhancement looks very useful.

Best regards,
Andrei Yahorau

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Konstantin Malanchev 2019-07-09 09:50:31 PGSQL 11.4: shared_buffers and /dev/shm size
Previous Message Andrey Sychev 2019-07-09 08:06:09 Re: Error: rows returned by function are not all of the same row type