Re: Recovery from WAL archives not advancing timeline?

On 2020/08/09 0:59, Don Seiler wrote:
> On Sat, Aug 8, 2020 at 10:34 AM Ian Lawrence Barwick <barwick(at)gmail(dot)com <mailto:barwick(at)gmail(dot)com>> wrote:
>
> 2020年8月9日(日) 0:12 Don Seiler <don(at)seiler(dot)us <mailto:don(at)seiler(dot)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'

Unfortunately it's not practical to verify what setting the server has in Pg11
and earlier. Is restarting the server an option? I'm sure I'm not the only person who's
been in a situation where I'm sure I've done something and it turns out I hadn't.

The code path there should definitely attempt to fetch a history file if
"recovery_target_timeline = 'latest'", so it would be useful rule out the
possibility that the setting simply hasn't been applied before looking into
other potential causes.

> Can I set that parameter to a specific timeline (eg '2')? Or does it just take 'latest'?

Yes, you can explicitly specify the timeline, though as changing it would require a
server restart, I suggest restarting the server as-is to double-check whether
the "recovery_target_timeline = 'latest'" is being applied, and only if not
try setting it to "recovery_target_timeline = 2".

> 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?

It probably wouldn't do any harm in this case, but in general nothing good
ever came of speculatively moving/deleting files in the WAL directory.

Regards

Ian Barwick

--
Ian Barwick https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services