From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Cc: | "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-13 03:32:30 |
Message-ID: | 20180913033230.GC3578@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-13 03:37:36 | Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT |
Previous Message | Thomas Munro | 2018-09-13 02:55:02 | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |