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