recovery_target_time and WAL fetch with streaming replication

From: Hannes Erven <hannes(at)erven(dot)at>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: recovery_target_time and WAL fetch with streaming replication
Date: 2018-05-12 23:39:48
Message-ID: db72ec7f-695b-1977-1f30-b422b475bab8@erven.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

what is Postgresql's strategy when to fetch WAL from the master while in
streaming replication, and could it be tweaked?

I'm using a physical streaming replication slave to have a database
lagging behind about one month behind the primary, by setting
"recovery_target_time" to the desired point in time.
This setting is periodically advanced by a cronjob to allow the replica
to roll forward. It's a 10.3-1 install on Debian.

It seems that as soon as the slave needs new WAL data to reach the
requested target time, it will connect to the primary and fetch /all/
new WAL the primary has available for the slave's slot - up to "now",
ignoring the recovery_target_time.

So in my setup, the slave will connect to the primary once per month,
and download the whole next month's WAL data at once.

I do not care on which instance WAL is kept until needed, but I'd really
prefer if the transfer (and disk space requirement!) would be more
evenly distributed.

One option of course would be to use some transfer mechanism external to
Postgresql... but so far I'm thinking there must be any easier way?

Thanks & best regards,

-hannes

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2018-05-13 06:23:55 Re: recovery_target_time and WAL fetch with streaming replication
Previous Message Adrian Klaver 2018-05-12 18:19:30 Re: Domain based on TIMEZONE WITH TIME ZONE