Re: Recovery from WAL archives not advancing timeline?

From: Don Seiler <don(at)seiler(dot)us>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: Recovery from WAL archives not advancing timeline?
Date: 2020-08-08 15:59:10
Message-ID: CAHJZqBB-TXuPS4R2M9N0mHSQUc8OjNwCkttE4q21-Cskhe+kbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Sat, Aug 8, 2020 at 10:34 AM Ian Lawrence Barwick <barwick(at)gmail(dot)com>
wrote:

> 2020年8月9日(日) 0:12 Don Seiler <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'

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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Don Seiler 2020-08-08 16:10:24 Re: Recovery from WAL archives not advancing timeline?
Previous Message Ian Lawrence Barwick 2020-08-08 15:33:54 Re: Recovery from WAL archives not advancing timeline?