Re: [PATCH] Fix timeline history after recovery stops on an ancestor

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com>
Cc: Филиппов Степан <stepan(dot)filippov(at)yandex(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "heikki(dot)linnakangas(at)iki(dot)fi" <heikki(dot)linnakangas(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: [PATCH] Fix timeline history after recovery stops on an ancestor
Date: 2026-08-27 11:17:31
Message-ID: B1BD458E-8408-45C6-820C-9FABFC17A8CC@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Stepan, Andrey,

I agree that lastRecTLI is the right parent here. It is already used as
PrevTimeLineID for the end-of-recovery record. endOfLogTLI would not be
a substitute: in the 028 scenario it is the timeline in the segment
name, not the timeline of the last replayed record.

It seems to me that 002_archiving.pl has a race. Generating and
archiving WAL on timeline 2 does not guarantee that standby2 replays it
before promotion. It can still be promoted while lastRecTLI is 1, so
the test would not prove that the restored timeline 2 history was used.
I think it needs to wait for the recorded timeline_2_lsn before calling
promote(), for example:

$caughtup_query =
"SELECT '$timeline_2_lsn'::pg_lsn <= pg_last_wal_replay_lsn()";
$node_standby2->poll_query_until('postgres', $caughtup_query)
or die "Timed out while waiting for standby2 to reach timeline 2";

Thank you!

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-08-27 11:35:58 Re: [PATCH] Fix disabled_nodes propagation for single-child Append paths
Previous Message Daniel Gustafsson 2026-08-27 11:13:21 Re: right() returns the whole string for the most negative n