From: Michael Paquier [mailto:mich...@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, because it'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, but I recommend adding how to specify wal_sender_timeout in primary_conninfo, because libpq's options parameter may not be well-konown, and it's a bit difficult to figure out the need to enclose the value with double single-quotes. Regards Takayuki Tsunakawa
