AW: AW: Reducing bandwidth usage of database replication - Mailing list pgsql-general
Thanks, the wal_sender_timeout setting was the culprit!
A bit hard to find that it influences a ping at half its interval time though.
| ||
Gessler GmbH Gutenbergring 14 63110 Rodgau Deutschland |
Geschaeftsfuehrer: Helmut Gessler, Dipl.-Ing. Marcus Gessler
Gerichtsstand: Offenbach/Main, Amtsgericht Offenbach HRB 20857
USt.-IdNr.: DE 113 551 141
Sparkasse Dieburg, IBAN DE94 5085 2651 0057 0025 03, SWIFT HELADEF1DIE
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail
und/oder der Inhalte dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material of this e-mail is strictly forbidden.
Gerichtsstand: Offenbach/Main, Amtsgericht Offenbach HRB 20857
USt.-IdNr.: DE 113 551 141
Sparkasse Dieburg, IBAN DE94 5085 2651 0057 0025 03, SWIFT HELADEF1DIE
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail
und/oder der Inhalte dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material of this e-mail is strictly forbidden.
Von: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Gesendet: Montag, 7. November 2022 06:21
An: Sascha Zenglein <zenglein@gessler.de>
Cc: simon.riggs@enterprisedb.com <simon.riggs@enterprisedb.com>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Betreff: Re: AW: Reducing bandwidth usage of database replication
Gesendet: Montag, 7. November 2022 06:21
An: Sascha Zenglein <zenglein@gessler.de>
Cc: simon.riggs@enterprisedb.com <simon.riggs@enterprisedb.com>; pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Betreff: Re: AW: Reducing bandwidth usage of database replication
At Fri, 4 Nov 2022 09:25:44 +0000, Sascha Zenglein <zenglein@gessler.de> wrote in
> I have set the status interval to 600s and it still sends a status message every 30s.
> I also tried setting every available option higher, with no success:
I guess you are not setting wal_sender_timeout on the primary side.
Status messages are also sent in response to sender pings that is
controlled by that variable. Wal sender sends a ping after a half of
that setting since the last status message to request walreceiver to
send a response.
> checkpoint_warning = 93s
> max_standby_streaming_delay = 130s
> max_standby_archive_delay = 45s
> wal_receiver_status_interval = 600s
> wal_receiver_timeout = 1200s
> wal_receiver_timeout = 65s
> recovery_min_apply_delay = 600s
>
> The random values were to see which setting is limiting if I got above the 30s limit.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
> I have set the status interval to 600s and it still sends a status message every 30s.
> I also tried setting every available option higher, with no success:
I guess you are not setting wal_sender_timeout on the primary side.
Status messages are also sent in response to sender pings that is
controlled by that variable. Wal sender sends a ping after a half of
that setting since the last status message to request walreceiver to
send a response.
> checkpoint_warning = 93s
> max_standby_streaming_delay = 130s
> max_standby_archive_delay = 45s
> wal_receiver_status_interval = 600s
> wal_receiver_timeout = 1200s
> wal_receiver_timeout = 65s
> recovery_min_apply_delay = 600s
>
> The random values were to see which setting is limiting if I got above the 30s limit.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment
pgsql-general by date: