If you did not even see this messages on your standby logs:
restartpoint starting: xlog
then it means that the checkpoint was even never started.
In that case, I have no clue.
Try to describe step by step how to reproduce the problem together with
your setup and the version number of Postgres a
standby_mode = 'on'
primary_conninfo = 'host=X.X.X.X user=repmgr connect_timeout=10 '
recovery_target_timeline = 'latest'
primary_slot_name = repmgr_slot_1
restore_command = 'rsync -avzhe ssh postgres@x.x.x.x:/var/lib/pgsql/archive/%f
/var/lib/pgsql/archive/%f ; gunzip < /var/lib/pgsql/archive/%f
Hi Mariel,
let s keep the list in cc...
settings look ok.
what's in the recovery.conf file then?
regards,
fabio pardi
On 5/27/19 11:23 AM, Mariel Cherkassky wrote:
> Hey,
> the configuration is the same as in the primary :
> max_wal_size = 2GB
> min_wal_size = 1GB
> wal_buffers = 16MB
> chec
Hi Mariel,
if i m not wrong, on the secondary you will see the messages you
mentioned when a checkpoint happens.
What are checkpoint_timeout and max_wal_size on your standby?
Did you ever see this on your standby log?
"consistent recovery state reached at .."
Maybe you can post your whole con
Hey,
PG 9.6, I have a standalone configured. I tried to start up a secondary,
run standby clone (repmgr). The clone process took 3 hours and during that
time wals were generated(mostly because of the checkpoint_timeout). As a
result of that, when I start the secondary ,I see that the secondary keep
