From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Paquier' <michael(at)paquier(dot)xyz> |
Cc: | 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Changing the setting of wal_sender_timeout per standby |
Date: | 2018-09-21 02:28:07 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FAB49D4@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Michael Paquier [mailto:michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-09-21 02:39:43 | Strange failure in LWLock on skink in REL9_5_STABLE |
Previous Message | Stephen Cook | 2018-09-21 02:23:57 | Re: Code of Conduct |