From: Michael Paquier [mailto:michael@paquier.xyz]
> But that does not apply to this single parameter, no? I would think that
> a section in recovery.conf is more adapted. I can see that the patch I
> proposed up-thread could be more precise though, so why not adding at an
> extra paragraph? Here is an idea:
> "For a cluster distributed across multiple geographic locations, using a
> different value per location brings more flexibility in the cluster
> management. A smaller value is useful for faster failure detection with
> a standby having a low connection latency, and a larger value helps
> judging better the health of a standby if located in a remote location,
> with a longer connection latency."
That paragraph looks cool, thanks. Regarding where the paragraph should be, there are three candidate locations:
(1) 19.6.1. Sending Servers, wal_sender_timeout description
https://www.postgresql.org/docs/devel/static/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER
(2) 26.2.4. Setting Up a Standby Server
https://www.postgresql.org/docs/devel/static/warm-standby.html#STANDBY-SERVER-SETUP
(3) 27.3. Standby Server Settings, primary_conninfo description
https://www.postgresql.org/docs/devel/static/standby-settings.html
I think all of these are almost equally good. I chose (1) at first, and you chose (3). But (2) may be the best,
becauseit's the natural place the user will see when configuring the standby, and it already contains an example of
recovery.conf. We can add "options=''-c wal_sender_timeout=5000''" or something in that example. I'm OK with anyplace,
butI recommend adding how to specify wal_sender_timeout in primary_conninfo, because libpq's options parameter may not
bewell-konown, and it's a bit difficult to figure out the need to enclose the value with double single-quotes.
Regards
Takayuki Tsunakawa