recovery_target_time and WAL fetch with streaming replication - Mailing list pgsql-general

From Hannes Erven
Subject recovery_target_time and WAL fetch with streaming replication
Date
Msg-id db72ec7f-695b-1977-1f30-b422b475bab8@erven.at
Whole thread Raw
Responses Re: recovery_target_time and WAL fetch with streaming replication  (Michael Paquier <michael@paquier.xyz>)
List 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


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Domain based on TIMEZONE WITH TIME ZONE
Next
From: Michael Paquier
Date:
Subject: Re: recovery_target_time and WAL fetch with streaming replication