Re: Fix logging for invalid recovery timeline
David Steele <david@pgbackrest.org>
From: David Steele <david@pgbackrest.org>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-24T16:04:20Z
Lists: pgsql-hackers
On 12/20/24 23:28, Andrey M. Borodin wrote:
>
>> On 20 Dec 2024, at 20:37, David Steele <david@pgbackrest.org> wrote:
>>
>> "Latest checkpoint is at %X/%X on timeline %u, but in the history of the requested timeline, the server forked off from that timeline at %X/%X."
>
> I think errdetai here is very hard to follow. I seem to understand what is going on after reading errmsg, but errdetai makes me uncertain.
Yeah, this one confuses users a lot. We see it mostly when a user
accidentally promotes a standby and that standby pushes a history file
and maybe some WAL on a new timeline, e.g. 2. The original primary
continues to make backups on the original timeline 1. At some point a
restore is required and Postgres by default wants to recover to the most
recent timeline, but timeline 2 forks from timeline 1 before the latest
backup was started so it is not accessible.
The solution is to set the target timeline to current but first the user
needs this figure out what is going on an this error message just
doesn't contain enough information to do that. I have some ideas on how
to make it better but that would probably be for HEAD only.
> If we call "tliSwitchPoint(CheckPointTLI, expectedTLEs, NULL);"
> don't we risk to have again
> ereport(ERROR,
> (errmsg("requested timeline %u is not in this server's history",
> tli)));
> ?
I'm not sure what you mean. For primary backups CheckPointTLI will
always equal ControlFile->checkPointCopy.ThisTimeLineID so that
shouldn't be a problem. For standby backups CheckPointTLI will be <=
ControlFile->checkPointCopy.ThisTimeLineID since CheckPointTLI
represents the timeline at the start of the backup. If a route from that
timeline to the current timeline can't be found then I'd certainly
expect an error.
I'll add this patch to the January CF.
Regards,
-David
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve FATAL message for invalid TLI history at recovery
- adc6032fa882 18.0 landed
-
Fix FATAL message for invalid recovery timeline at beginning of recovery
- 62bed7bb0f6c 15.13 landed
- b4969a29657d 16.9 landed
- 29cce279bbc5 17.5 landed
- 71f17823ba01 18.0 landed