Re: Recovery from WAL archives not advancing timeline? - Mailing list pgsql-admin

From Don Seiler
Subject Re: Recovery from WAL archives not advancing timeline?
Date
Msg-id CAHJZqBB-TXuPS4R2M9N0mHSQUc8OjNwCkttE4q21-Cskhe+kbg@mail.gmail.com
Whole thread Raw
In response to Re: Recovery from WAL archives not advancing timeline?  (Ian Lawrence Barwick <barwick@gmail.com>)
Responses Re: Recovery from WAL archives not advancing timeline?  (Don Seiler <don@seiler.us>)
Re: Recovery from WAL archives not advancing timeline?  (Ian Barwick <ian.barwick@2ndquadrant.com>)
List pgsql-admin
On Sat, Aug 8, 2020 at 10:34 AM Ian Lawrence Barwick <barwick@gmail.com> wrote:
2020年8月9日(日) 0:12 Don Seiler <don@seiler.us>:
>
> There's no attempt to look for 00000002.history that I would normally expect when a replica doing WAL restore/recovery runs of out of files to restore.

In that case are you
a) absolutely sure recovery.conf contains "recovery_target_timeline = 'latest'"?
b) the standby was restarted *after* the change was made?

I ask because not attempting to fetch a history file would be a sign
that "recovery_target_timeline"
is not set (or set but not to "latest").

I'm 100% confident that it was set, as I did it via script that wrote the recovery.conf to all while the DBs were still shut down. The file still has:

recovery_target_timeline = 'latest'

Can I set that parameter to a specific timeline (eg '2')? Or does it just take 'latest'?
 
From the timestamps, 000000010000142E0000005C and later are files
which were "recycled"
for future use and as such are perfectly normal.

Do you think it would be worth trying to delete (move/rename) the 000000010000142E0000005B file and see if it changes things?

--
Don Seiler
www.seiler.us

pgsql-admin by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: Recovery from WAL archives not advancing timeline?
Next
From: Don Seiler
Date:
Subject: Re: Recovery from WAL archives not advancing timeline?