RE: Changing the setting of wal_sender_timeout per standby
Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Michael Paquier' <michael@paquier.xyz>
Cc: 'Masahiko Sawada' <sawada.mshk@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-21T02:28:07Z
Lists: pgsql-hackers
From: Michael Paquier [mailto:michael@paquier.xyz] > Thanks for the new version. Per my comments up-thread here, you cannot > actually use PGC_BACKEND: > https://www.postgresql.org/message-id/20180919061303.GB19808@paquier.x > yz > > This would break the case where this parameter is reloaded when a session > does not use a custom value for wal_sender_timeout. I have also looked > at all the code paths using wal_sender_timeout, and the change looks safe > to me. Please find attached an update, simplified, version. > Does that look fine to you? Thank you, PGC_USERSET is off course fine to me. I thought PGC_BACKEND includes the capability of PGC_SIGHUP, because PGC_BACKEND is placed after PGC_SIGHUP in the definition of enum GucContext. That was a pitfall. I should have paid more attention. I find it more user friendly to include a description somewhere that the user can tune the timeout per standby, like I added a tip in the description of wal_sender_timeout. I'm afraid users won't know whether and how to tune the setting per standby, as libpq's options parameter doesn't seem well-known in my experience. Regards Takayuki Tsunakawa
Commits
-
Make GUC wal_sender_timeout user-settable
- db361db2fce7 12.0 landed