Re: Changing the setting of wal_sender_timeout per standby

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: sawada(dot)mshk(at)gmail(dot)com
Cc: michael(at)paquier(dot)xyz, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Changing the setting of wal_sender_timeout per standby
Date: 2018-09-18 02:20:03
Message-ID: 20180918.112003.67119579.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoBr2Y=N4iH8+6m5ara2GWdKE6ZrzWaqjZux6ErZ9pyAxQ(at)mail(dot)gmail(dot)com>
> On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Thu, Sep 13, 2018 at 01:14:12AM +0000, Tsunakawa, Takayuki wrote:
> >> Some customer wants to change the setting per standby, i.e., a shorter
> >> timeout for a standby in the same region to enable faster detection
> >> failure and failover, and a longer timeout for a standby in the remote
> >> region (for disaster recovery) to avoid mis-judging its health.
> >
> > This argument is sensible.
> >
> >> The current PGC_HUP allows to change the setting by editing
> >> postgresql.conf or ALTER SYSTEM and then sending SIGHUP to a specific
> >> walsender. But that's not easy to use. The user has to do it upon
> >> every switchover and failover.
> >>
> >> With PGC_BACKEND, the user would be able to tune the timeout as follows:
> >>
> >> [recovery.conf]
> >> primary_conninfo = '... options=''-c wal_sender_timeout=60000'' ...'
> >>
> >> With PGC_USERSET, the user would be able to use different user
> >> accounts for each standby, and tune the setting as follows:
> >>
> >> ALTER USER repluser_remote SET wal_sender_timeout = 60000;
> >
> > It seems to me that switching to PGC_BACKENDwould cover already all the
> > use-cases you are mentioning, as at the end one would just want to
> > adjust the WAL sender timeout on a connection basis depending on the
> > geographical location of the receiver and the latency between primary
> > and standby.
>
> +1 for PGC_BACKEND. It looks enough for most use cases.

+1, and we need a means to see the actual value, in
pg_stat_replication?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-09-18 02:38:50 Re: Problem while setting the fpw with SIGHUP
Previous Message Thomas Munro 2018-09-18 01:18:56 Re: [PATCH] Fix for infinite signal loop in parallel scan