| From: | Филиппов Степан <stepan(dot)filippov(at)yandex(dot)ru> |
|---|---|
| To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | "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-09-07 09:47:15 |
| Message-ID: | 136551788773962@mail.yandex.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
27.08.2026, 16:17, "Andrey Borodin" <x4mmm(at)yandex-team(dot)ru>:
> 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";
Hi, Andrey!
Thank you for the review. You are right, there is a race.
In v2 i added suggested query to wait timeline_2_lsn. This will help
to avoid promotion before timeline2 is applied.
Best regards, Stepan Filippov.
| Attachment | Content-Type | Size |
|---|---|---|
| unknown_filename | text/html | 1.1 KB |
| 0001-v2-Fix-history-after-recovery-stops-on-an-ancestor.patch | text/x-diff | 3.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2026-09-07 10:05:57 | Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row |
| Previous Message | Amit Kapila | 2026-09-07 09:42:06 | Re: Follow-up review items for update_deleted |