From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Changing the setting of wal_sender_timeout per standby |
Date: | 2018-09-13 01:14:12 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FAAD3AE@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
What do you think about changing wal_sender_timeout from PGC_HUP to PGC_BACKEND or PGC_USERSET?
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.
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;
FYI
In Oracle Data Guard, the user configures the timeout for each standby in the primary server's configuration file like this:
LOG_ARCHIVE_DEST_1 = "SERVICE=local_conn_info SYNC NET_TIMEOUT=5"
LOG_ARCHIVE_DEST_2 = "SERVICE=remote_conn_info ASYNC NET_TIMEOUT=60"
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-09-13 02:55:02 | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |
Previous Message | Tom Lane | 2018-09-13 00:38:26 | Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused |