RE: Changing the setting of wal_sender_timeout per standby

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
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:
> 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.

Takayuki Tsunakawa

In response to


Browse pgsql-hackers by date

  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